- Thu Jan 05, 2017 4:41 pm
#60503
The three boot modes available are:
GPIO15 GPIO0 GPIO2 Mode Description
L L H UART Download code from UART
L H H Flash Boot from SPI Flash
H x x SDIO Boot from SD-card
Question 1
========
If GPIO15 = GPIO0 = GPIO2 = L
or
GPIO15 = L
GPIO0 = H
GPIO2 = L
then in which mode does the ESP boot to?
Question 2 -> this is the main question
========
I have the same trouble as the OP in https://github.com/esp8266/Arduino/issues/1017
Specifically, my adaptor-powered ESP8266 (NodeMCU v1) WDT-resets every one to three days and then becomes irresponsive unless I manually reset it. To my best understanding the only thing that could be triggering the irresponsiveness is the chip entering UART programming mode after the WDT reset.
I had seen this behavior directly in the logs of the serial port at the time of sketch development -- at that time I had several problems with wdt resets which I thought (at least that's what it seemed) I resolved with volatge stabilizing capacitors.
To prevent the chip from entering firmware write mode after a wdt reset, I would gladly pull the 3 IOs to the correct levels, however, two of them are already used in my sketch for driving a touch TFT (see the wiring at http://nailbuster.com/?page_id=341)) and thus I only have control over GPIO0. So, even if I pulled up GPIO0 I can never guarantee the correct state for the other two pins after an (unpredictable) wdt reset.
Please let me know if you have any suggestions, workarounds for my specific problem. However, I am also worried about another relevant issue:
In https://github.com/esp8266/Arduino/issu ... -156703421 , igrr mentions that despite the necessary pullups, sometimes his nodemcu enters bootloader after wdt reset (surprisingly)
So arises the burning Question 2
Is there a *reliable* way to *reliably* bring the esp into sketch execution mode after a wdt reset??? -> this is "Question 2".
And since in real-life situations the possibility of a wdt reset cannot be obliterated, I believe this question deserves a clear answer.
Question 3
========
In https://github.com/esp8266/Arduino/issu ... -200605576 igrr mentions that the bootloader doesn't *actually* sample the 3 pins to decide on the boot mode [that's creepy], but instead does something else which is explained in the rest of igrr's comment.
Could you please expand more on the explanation provided since I cannot fully understand it???
Hope you don't mind the large post!!
Happy New Year!!!!
GPIO15 GPIO0 GPIO2 Mode Description
L L H UART Download code from UART
L H H Flash Boot from SPI Flash
H x x SDIO Boot from SD-card
Question 1
========
If GPIO15 = GPIO0 = GPIO2 = L
or
GPIO15 = L
GPIO0 = H
GPIO2 = L
then in which mode does the ESP boot to?
Question 2 -> this is the main question
========
I have the same trouble as the OP in https://github.com/esp8266/Arduino/issues/1017
Specifically, my adaptor-powered ESP8266 (NodeMCU v1) WDT-resets every one to three days and then becomes irresponsive unless I manually reset it. To my best understanding the only thing that could be triggering the irresponsiveness is the chip entering UART programming mode after the WDT reset.
I had seen this behavior directly in the logs of the serial port at the time of sketch development -- at that time I had several problems with wdt resets which I thought (at least that's what it seemed) I resolved with volatge stabilizing capacitors.
To prevent the chip from entering firmware write mode after a wdt reset, I would gladly pull the 3 IOs to the correct levels, however, two of them are already used in my sketch for driving a touch TFT (see the wiring at http://nailbuster.com/?page_id=341)) and thus I only have control over GPIO0. So, even if I pulled up GPIO0 I can never guarantee the correct state for the other two pins after an (unpredictable) wdt reset.
Please let me know if you have any suggestions, workarounds for my specific problem. However, I am also worried about another relevant issue:
In https://github.com/esp8266/Arduino/issu ... -156703421 , igrr mentions that despite the necessary pullups, sometimes his nodemcu enters bootloader after wdt reset (surprisingly)
So arises the burning Question 2
Is there a *reliable* way to *reliably* bring the esp into sketch execution mode after a wdt reset??? -> this is "Question 2".
And since in real-life situations the possibility of a wdt reset cannot be obliterated, I believe this question deserves a clear answer.
Question 3
========
In https://github.com/esp8266/Arduino/issu ... -200605576 igrr mentions that the bootloader doesn't *actually* sample the 3 pins to decide on the boot mode [that's creepy], but instead does something else which is explained in the rest of igrr's comment.
Could you please expand more on the explanation provided since I cannot fully understand it???
Hope you don't mind the large post!!
Happy New Year!!!!
