HttpUpdate not booting properly

[adrian-dybwad]

I managed to get the httpUpdate working except that it was crashing soon after writing out one line to the serial port.
My httpUpdate call is as follows:
t_httpUpdate_return ret = ESPhttpUpdate.update(host, port, url, currentver);

After comparing the process to the POST update example, I found that the _startAddress value in Updater.cpp was different between the WebUpdate example and the httpUpdate method.
In the POST method, the _startAddress was basically the existing sketch size and in the httpUpdate it was the remaining free space less the new sketch size.

After changing the Updater.cpp file as follows, it started working:
Line 74:
updateStartAddress = currentSketchSize ;//(WAS) updateEndAddress - roundedSize;

Why is the updateStartAddress different between the httpUpdate method and the WebUpdate POST example?
What would the correct fix be?

What a wonderful feature this OTA update is!!

[me-no-dev]

the correct way is to start at least after the current sketch rounded up to a block.
I see no reason for them not to work.
Main difference is that the POST example does not know the size of the incoming sketch so it reserves all of the available space, minus the EEPROM.

[Links2004]

can you provide a serial log with:

Serial.setDebugOutput(true);

and enable the debugs for the update:
https://github.com/esp8266/Arduino/blob/master/cores/esp8266/Updater.cpp#L6
https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266httpUpdate/src/ESP8266httpUpdate.h#L35

[adrian-dybwad]

I found the cause. I had an incorrect flash memory size (larger than the chip) and so the startaddress was calculated incorrectly.

The httpupdateserver example works due to the startaddress being just after the existing sketch, where the httpupdate library does not since it somehow uses the size of flash (reported by compiler?).

The exact situation was setting the flash memory to 4M (Adafruit Huzzah) and writing the sketch to a 1M ESP-07.

Curiously, EEPROM works. I do not use SPIFFS and suspect it may have problems in this situation.

Would it be an idea for the update library to use the chip reported size rather than the compiler reported - if that is what's happening?

[Links2004]

if the chip size is wrong selected, this will make many problems,
simply using the real one in not that easy, since the memory regions are different and they are configured during compile time (linker files).
but its possible cancel the update when the current settings are wrong, by this its easier to see that there is a problem.
@igrr may we shut implement a check before setup call for correct flash settings, and if they wrong do printing a error before running the sketch.

[adrian-dybwad]

Yes, sounds great. Why would EEPROM work with incorrect memory size setting?

[Links2004]

EEPROM is located after SPIFFS not change that it work.
your are sure it survive a power lost? there is a copy in RAM that is used for all operations.

[adrian-dybwad]

Yes, EEPROM works just fine - after restart, even with 4M compiler size on a 1M chip.

[Links2004]

strange, may the flash ship do some sort of mirroring inside.

[adrian-dybwad]

While you are working on this, I added another two HTTP_UPDATE flags:
In ESP8266HTTPUpdate.h added HTTP_UPDATE_NOT_FOUND and HTTP_UPDATE_NO_SPACE,

typedef enum {
    HTTP_UPDATE_FAILED,
    HTTP_UPDATE_NOT_FOUND,
    HTTP_UPDATE_NO_SPACE,
    HTTP_UPDATE_NO_UPDATES,
    HTTP_UPDATE_OK
} t_httpUpdate_return;

In ESP8266HTTPUpdate.cpp

                if(len > ESP.getFreeSketchSpace()) {

                    ret = HTTP_UPDATE_NO_SPACE;
                    DEBUG_HTTP_UPDATE("[httpUpdate] FreeSketchSpace too low (%d) needed: %d\n", ESP.getFreeSketchSpace(), len);
...

And another status code (404) check to make debugging server side easier:

        case 304:
            ///< Not Modified (No updates)
            ret = HTTP_UPDATE_NO_UPDATES;
            break;
        case 404:
            ///< Server error (Not found)
            ret = HTTP_UPDATE_NOT_FOUND;
            break;

[adrian-dybwad]

I also added a boolean to the ESP8266HTTPUpdate::update and handleUpdate functions to optionally stop it from restarting the ESP so I can complete some things before a restart after an update...

[Links2004]

reboot handling is added already
https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266httpUpdate/src/ESP8266httpUpdate.h#L52
more detail on fail, is not easy to add sine more return values will brake all existing code.
will think about possibilities.