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.
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
Provide a way to bypass the automatic load() on ESP8266 #661
Comments
@nkolban |
@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. |
... 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 |
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. |
Flash blank.bin to 0x7C000. The flash layout is documented in https://github.com/espruino/Espruino/wiki/ESP8266-Design-Notes |
@rakeshpai can this be closed ? |
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:
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.
The text was updated successfully, but these errors were encountered: