OTA only works the first time

[hasiflo]

Basic Infos

• [ x] This issue complies with the issue POLICY doc.
• [ x] I have read the documentation at readthedocs and the issue is not addressed there.
• [x ] I have tested that the issue is present in current master branch (aka latest git).
• [x ] I have searched the issue tracker for a similar issue.
• [ x] If there is a stack dump, I have decoded it.
• [x ] I have filled out all fields below.

Platform

• Hardware: [ESP-12]
• Core Version: [2018/03/21]
• Development Env: [Arduino IDE]
• Operating System: [Ubuntu]

Settings in IDE

• Module: [Generic ESP8266 Module]
• Flash Mode: [qio|]
• Flash Size: [1MB]
• lwip Variant: [v2 Lower Memory]
• Reset Method: [ck]
• Flash Frequency: [40Mhz]
• CPU Frequency: [80Mhz]
• Upload Using: [OTA|SERIAL]
• Upload Speed: [115200|]

Problem Description

I use ESP8266httpUpdate.h for updating the code on an ESP8266 with 1M (no spiffs).
Code Size:
Sketch uses 339,333 bytes (33%) of program storage space. Maximum is 1,023,984 bytes. Global variables use 36,168 bytes (44%) of dynamic memory, leaving 45,752 bytes for local variables. Maximum is 81,920 bytes.

So the problem is, I can update over the air only once and all is good.
But if I try a second update (the same code and size), I get the error 'not enough space'.

Is it possible, that the old programm will not be removed?
Can I manually clean the space between the actual programm and SPIFFS?
Is it enough, if the programm is less than 50% of the memory-size (in case of no spiffs) or how many space has to be free?

[Marc-Vreeburg]

I am experiencing something similar.
After flashing with uart/com port, flashing with OTA does not work. The ip adres can be seen and selected in ide menu, however flashing with OTA results in error: the selected serial port does not exist or your board has not been connected.

• Does work: flashing with uart/com multiple times;
• Does work: flashing with OTA multiple times;
• Does no work: flashing with uart/com and then flashing with OTA.

[devyte]

@marcvtew not the same. After flashing over serial you have to physically reset the esp before doing OTA. This is a known issue for which there is no known fix or workaround.

[Marc-Vreeburg]

@devyte
Flashed wrong board to my lolin esp resulting in strange behavior. My bad.

@hasiflo
Tested:
flashing with uart/com multiple times: works flawlessly
flashing with OTA multiple times: works flawlessly
flashing with httpUpdate multiple times: works flawlessly

Try an esp8266 with 4 Mb flash and see if your problem still exists.

[Marc-Vreeburg]

I have tested ESPhttpUpdate with a more elaborate piece of code and now i am experiencing a locked up esp8266 (no update either) using:

latest git version 2.4.1 + deepsleep() + ESPhttpUpdate

Core version 2.3.0 + deepsleep() + ESPhttpUpdate works for me.
Next week i'll do some more testing.

[Marc-Vreeburg]

Finally figured out what was going on. Nothing to do with ESPhttpUpdate (no reboot after update). Not rebooting seems to be related to max sleeptime for deepsleep(). I used to sleep the module for 3600000000 microseconds without any problem. With latest git version of master branch this seems to long and the esp8266 does not recover from deepsleep. I think it has to do with sdk 2.1.0 and the modifications made to git master branch.

[devyte]

@marcvtew That is correct. There is a function in the ESPClass that tells you how long you can (theoretically) sleep. It is a direct implementation of Espressif's SDK documentation.

[Marc-Vreeburg]

@devyte Tested the changes made to esp.cpp and esp.h (from uint32_t to uint64_t). My conclusion is that esp8266 does not recover from deepsleep but hangs in an onresponsive state. Looks related to #4071.
For the record: my code works pefectly without the changes made in esp.h and esp.cpp.

[Marc-Vreeburg]

@hasiflo Tested ESPhttpUpdate. I cannot confirm your findings and think your issue (#4831) should be closed.

[Marc-Vreeburg]

@devyte I overlooked max sleeptime. Sleeptime has indeed been extended (max around 3.5 hours). Only drawback: sleeping for more than max sleeptime leaves esp8266 in an unresponsive state without any warning (sketch compiles without errors).

[devyte]

@marcvtew that is correct, and is a direct reflection of how the sdk works. I suppose some error handling could be implemented on our end, e.g. error out if attempt to sleep for longer than maxsleeptime. Want to make a PR with that?

[devyte]

Closing as can't reproduce per @marcvtew . Thanks!

[Marc-Vreeburg]

@devyte Maybe adapting deepSleep class like this?

void EspClass::deepSleep(uint64_t time_us, WakeMode mode)
{
    uint64_t time_us_deepsleep_max = deepSleepMax();
    if (time_us > time_us_deepsleep_max)
    {
		
         // generate a warning compiling the code
			 
    }
    system_deep_sleep_set_option(static_cast<int>(mode));
    system_deep_sleep(time_us);
    esp_yield();
}

[devyte]

You can't generate a compile time warning based on a runtime condition. I suggest changing the return type, and if the max is exceeded, return an error. It will be up to the user to check that a sleep didn't fail.

[Marc-Vreeburg]

Changed return type to bool:

bool EspClass::deepSleep(uint64_t time_us, WakeMode mode)
{
    if (time_us > deepSleepMax())
    {
        #ifdef DEBUG_SERIAL
           DEBUG_SERIAL.print("Error: max sleeptime exceeded");
        #endif
        return 0; // error: max sleeptime exceeded
    }
   else
   {
    system_deep_sleep_set_option(static_cast<int>(mode));
    system_deep_sleep(time_us);
    esp_yield();
    return 1; // never gets called
   }
}