ESP8266 Community Forum

- Mon May 14, 2018 2:27 am #75925 Hello,

In my ESP8266 projects, in case of MQTT connection loss with reconnection failure, after a number of minutes, I restart the ESP8266 via ESP.restart(). I do not really know why this MQTT connection loss (or WiFi) happen, but it would be a subject for another messages thread (some of my ESP8266 are running for months 24 hours a day and 7 days a week without any loss of MQTT connection, others may experience this connection loss twice a month).

So, in the case of this connection MQTT loss without possible reconnection, I restart the ESP via ESP.restart() and usually the problem is self-resolved by the code. Great! But from time to time, unfortunately, I notice this not happen properly. The ESP8266 no longer responds to ping otherwise. In this case, I turn it off and then on, it works again immediately. Notice that this problem has nothing to do with this issue : you have to power off/on after serial flash programming (I know this issue).

I'm therefore looking for the solution that would allow me to be 100% sure (if 100% is possible) that the ESP8266 will reboot (correctly). I was thinking of replacing the ESP.restart() with an ESP.reset(). Also, this messages thread (viewtopic.php?f=32&t=9459&start=8) mentions a issue that could be mine and recommends to flash in DIO mode instead of QIO.

To come to my questions:

 1. Regarding ESP.reset() instead of ESP.restart(), I use currently ESP.restart() because the web mentions without many details (I imagine everyone is copying each others) that ESP.restart() is better than ESP.reset() that could leave initialized registers. But which registers? And I must say that I do not understand this problem because if ESP.reset() is like a Power ON, how when you turn on your ESP8266, you could get an issue? And so how an ESP.reset() is a potential issue?
 
2. I looked in the ESPclass code to find what ESP.restart() and ESP.reset() do. I found
extern "C" void __real_system_restart_local ();
void EspClass :: reset (void)
{
  __real_system_restart_local ();
}
void EspClass :: restart (void)
{
  system_restart ();
  esp_yield ();
}
Where can we find further information about what system_restart() and __real_system_restart_local() do?

3. Do we have more information today on this messages thread (viewtopic.php?f=32&t=9459&start=8) recommendations and why flashing DIO instead of QIO would cancel some non-reboot causes?

Finally, if I have to ask only one question, which way would you advise me to be more sure that ESP will reboot when I decide it by code.

- Fri Jun 08, 2018 11:21 am #76361 Hello,
Nobody for a beginning of anwer (did I ask stupid or too basic questions?)

- Fri Jun 08, 2018 11:44 am #76362 If you want to get 100% behaviour like reset, connect a gpio to rst and toggle it accordingly.
For behaviour like power up, use EN instead of rst.
If your flash chip is built for qio and connected accordingly, use qio mode, if in doubt use dio.
Bootloader (tries to) remember last flash mode and uses this on following boots (info might get corrupted, though).

- Tue Jul 24, 2018 2:22 pm #77408 Hi,

I have GPIO0 conected to RST and I am using ESP.deepSleep(1e6) to reset the board.

One question, how can I know which is the flash mode of my NodeMCU 1.0?