ESP.reset() / ESP.restart()

[tonton81]

have a weird issue
using latest GIT with arduino 1.8.3

After programming, the first call to ESP.reset() / ESP.restart() causes the esp8266 to completely lock up and throw the red light, using an adafruit breakout esp8266 board

to narrow things down, I put just ESP.reset() in the setup() function and started programming. After the programming, same issue, complete lockup with red light. however, pressing the reset button manually causes the code to work perfectly fine as its consistantly resetting the ESP fine every time it hits setup

does the bootloader set a flag that the first reset/restart doesnt like right after programming? has anyone seen this? manually resetting or pulling power and back make it run fine

[everslick]

thats not a bug. the EPS8266 reenters boot loader mode, if not reset via reset button or power circle. it's also documented this way.

[tonton81]

how come after programming sketches run fine without needing the button reset? its only the first time AFTER programming when calling reset completely locks up. otherwsie code runs fine right after programming as long as i dont call reset/restart

[tonton81]

where is this specific issue documented?

[tonton81]

i find it hard to believe sketches can run in bootloader mode right after programming but the esp.reset/restart requires an initial hard reset in order to exit bootloader mode that programming reentered even though the sketch runs normal code fine? heh...

[igrr]

What happens is basically:

• esptool-ck resets the chip into bootloader mode. This means that the chip is reset externally with GPIO0 pulled low. ROM bootloader starts, and checks the strapping register (which contains state of GPIOs 0, 1, 2, 15). It sees that GPIO0 is low and instead of loading the application from flash, starts waiting for UART communication.
• esptool-ck uploads the application into flash memory by taking to ROM bootloader over UART
• esptool-ck tells the bootloader to start the application. At this point the bootloader loads the (part of) application into RAM and jumps to the entry point.
• application runs. Then the code performs ESP.restart. This has the effect of jumping to the bootloader entry point. Bootloader checks the strapping register (which is not reloaded on soft reset), sees that GPIO0 is low, and goes into download mode, waiting for UART communication...

[tonton81]

so everytime after programming we have to hard reset in order not to get stuck like this?

[igrr]

Yes. It is possible for esptool-ck to do a hard reset after uploading, but this needs some testing...

[deskwizard]

Hi Igrr,
I have the same "issue" as tonton81.
Could you please elaborate on the comment about esptool-ck doing an hardware reset instead of the software reset?
You mentioned it's untested, any way I can test it myself?

Thank you

[jeroenst]

This brakes my functionality.... 👎

[d-a-v]

Maybe you could open a feature request in https://github.com/igrr/esptool-ck ?

[jeroenst]

it seems like when the esp8266 is not connected to the computer the ESP.reset and ESP.restart work without problem. Possible the USB->RS232 ic is making a pin high which is low when not connected to a pc?

Same thing applies for the watchdog afaik.

Anyhow it works fine now. Also I don't need the reset anymore, I needed it because when changing the hostname it didn't become active afterwards. But when I stop wifi and start it again the hostname also becomes active and a reset isn't needed.