Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Provide a way to bypass the automatic load() on ESP8266 #661

Closed
rakeshpai opened this issue Oct 14, 2015 · 8 comments
Closed

Provide a way to bypass the automatic load() on ESP8266 #661

rakeshpai opened this issue Oct 14, 2015 · 8 comments
Labels
enhancement ESP8266 This is only a problem on ESP8266 devices

Comments

@rakeshpai
Copy link

I've "bricked" my esp-12e. I uploaded some code that is causing the chip to reset due to the watchdog timer. This is what I see over serial:

wdt reset
load 0x40100000, len 29488, room 16 
tail 0
chksum 0xfa
load 0x3ffe8000, len 2108, room 8 
tail 4
chksum 0x08
load 0x3ffe8840, len 28828, room 4 
tail 8
chksum 0x09
csum 0x09
��n���sys=68168 rtc=14974437��;l�Loading 3438 bytes from flash...
�Got here


 ets Jan  8 2013,rst cause:4, boot mode:(3,6)

wdt reset
load 0x40100000, len 29488, room 16 
tail 0
chksum 0xfa
load 0x3ffe8000, len 2108, room 8 
tail 4
chksum 0x08
load 0x3ffe8840, len 28828, room 4 
tail 8
chksum 0x09
csum 0x09
��n���sys=68170 rtc=15116921��;l�Loading 3438 bytes from flash...
�Got here

The Got here message is from my code that's running on the chip, so it seems that the espruino interpretter runs correctly, and the loading of the code works fine too. It's probably something wrong with my code that causes it to mess up.

However, now that the chip is stuck, I can't seem to do anything with it to fix it. I've tried reflashing the chip, but that didn't seem to erase the code that was uploaded. Even after the reflash, my code is still picked up and executed, causing the reset again. Since the chip isn't responding, I can't reset() over serial to prevent the code from loading.

The troubleshooting page has hardware solutions to this problem, but there's understandably nothing there for the esp8266 chips.

Is this something we can build? Meanwhile, could you suggest something even as a stop-gap so that I can "unbrick" my chip.
@gfwilliams
Copy link
Member

@nkolban jsiInit takes a boolean - which should be false if BTN1 (or similar) is pressed - it'll stop it auto-loading code.

@nkolban
Copy link
Contributor

nkolban commented Oct 14, 2015

@rakeshpai The JS program that was previously saved is stored as bytes in flash memory. @tve added that area and I don't know where within the flash memory it is saved. We have to study and ask @tve where the code is saved. Once we know where it is saved, we can then use the firmware upload toold to write binary zeros at that location and the previously saved program will be gone.

@gfwilliams Thanks for that ... unfortunately, an ESP8266 doesn't have any "buttons" by default. We are going to have to give some thought to how we can signal Espruino not to load at boot. I suspect what we will do is make a configuration parameter that identifies a GPIO and tests that at startup.

@nkolban nkolban added the ESP8266 This is only a problem on ESP8266 devices label Oct 14, 2015
@gfwilliams
Copy link
Member

... other option is to wait ~1 sec after power on, and if someone's been bashing Ctrl+C then you know not to load stuff when you call jsiInit

@rakeshpai
Copy link
Author

If we are to go with the external GPIO method, we might really only have GPIO2 to work with, if we want to support the ESP-01.
ESP-01 pinout

I'm not sure how the ctrl+c method would work, but if we could come up with a method that's independent of the WebIDE, I'd prefer that.

@nkolban
Copy link
Contributor

nkolban commented Oct 14, 2015

Unfortunately, I don't think EITHER GPIO0 or GPIO2 can be used as signals at boot time. The GPIOs known as GPIO0, GPIO2 and GPIO15 are all examined by ESP8266 itself at boot time to determine what the ESP8266 itself should do. For example GPIO0 = low means flash while high means run. GPIO2 has similar semantics. After boot, they can be used as GPIO but in this story, it won't help us.

Other GPIOs can be used ... but, obviously, they aren't there on the ESP-1. My gut is saying that to reset an ESP-1, the story would be to erase its memory while for ESP-12, NodeMCU and other boards, we can use one of the other GPIOs.

@tve
Copy link
Contributor

tve commented Oct 14, 2015

Flash blank.bin to 0x7C000. The flash layout is documented in https://github.com/espruino/Espruino/wiki/ESP8266-Design-Notes

@nkolban
Copy link
Contributor

nkolban commented Oct 15, 2015

The esptool found here has an option called erase_flash that can erase all the flash of the ESP effectively resetting it. A request for an erase option for esptool-ck has been submitted.

User @HyGy has also run into this issue and I believe it won't be the last time before we are done.

@tve tve added the enhancement label Dec 7, 2015
@MaBecker
Copy link
Contributor

MaBecker commented Dec 9, 2016

@rakeshpai can this be closed ?

@nkolban nkolban closed this as completed Dec 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement ESP8266 This is only a problem on ESP8266 devices
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@tve @rakeshpai @gfwilliams @nkolban @MaBecker