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.

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

Bricked my ESP8266 #284

Closed
santiagopoli opened this issue May 19, 2015 · 14 comments
Closed

Bricked my ESP8266 #284

santiagopoli opened this issue May 19, 2015 · 14 comments

Comments

@santiagopoli
Copy link

Hi!

Yesterday I was experimenting with the ESP8266 and the Arduino IDE. I've made a program which connects to my Wifi and lets you turn a pin on and off. The problem is that I'm being unable to program my module again. I think the issue happened when I deleted the Serial.begin line in my code. The serial doesn't begin, so I'm unable to program it via FTDA.

Is there a way to reset the ESP to its factory settings or i'm doomed?

Thanks!

PS: I've tried to flash my firmware with both esptool and pyesptool and neither of them were able to connect to my ESP.

@meronz
Copy link

meronz commented May 19, 2015

What kind of error are you experiencing?
Did you try turning it on and off again? Maybe while you keep GPIO0 to low, try putting rst to low too and try to flash it.
You should be able to flash it again!

@santiagopoli
Copy link
Author

I tried everything. With pyesptool I get a "Failed to connect" error and with esptool I get a sync error.
I was able to flash the module with the same wiring. The problem started when I deleted the "Serial.begin(9600)" line in my code (in setup());

@santiagopoli
Copy link
Author

I will try putting RST to ground. I didn't try that

@Links2004
Copy link
Collaborator

try this setup:
https://github.com/esp8266/Arduino#minimal-hardware-setup-for-bootloading-only
then the esp never load you code and the boot-loading shut work.

@igrr
Copy link
Member

igrr commented May 19, 2015

As I understand, it's not possible to brick an esp by uploading some
firmware. The bootloader starts without even talking to the SPI flash. If
you have trouble communicating with the bootloader, it means the
bootstrapping pins are not in the correct states. Check that you apply
correct pull up/downs to GPIO 0, 2, 15, CH_PD, RST.
On May 19, 2015 22:24, "Markus" notifications@github.com wrote:

try this setup:

https://github.com/esp8266/Arduino#minimal-hardware-setup-for-bootloading-only
then the esp never load you code and the boot-loading shut work.


Reply to this email directly or view it on GitHub
#284 (comment).

@igrr
Copy link
Member

igrr commented May 19, 2015

That said, it's entirely possible to brick an esp by applying voltages that
exceed its absolute maximum ratings.
On May 19, 2015 22:28, "Ivan Grokhotkov" igrokhotkov@gmail.com wrote:

As I understand, it's not possible to brick an esp by uploading some
firmware. The bootloader starts without even talking to the SPI flash. If
you have trouble communicating with the bootloader, it means the
bootstrapping pins are not in the correct states. Check that you apply
correct pull up/downs to GPIO 0, 2, 15, CH_PD, RST.
On May 19, 2015 22:24, "Markus" notifications@github.com wrote:

try this setup:

https://github.com/esp8266/Arduino#minimal-hardware-setup-for-bootloading-only
then the esp never load you code and the boot-loading shut work.


Reply to this email directly or view it on GitHub
#284 (comment).

@santiagopoli
Copy link
Author

Thanks,
Can someone clarify on this?

if no RTS is used a manual power toggle is needed

El 19/5/2015, a las 16:28, Ivan Grokhotkov notifications@github.com escribió:

As I understand, it's not possible to brick an esp by uploading some
firmware. The bootloader starts without even talking to the SPI flash. If
you have trouble communicating with the bootloader, it means the
bootstrapping pins are not in the correct states. Check that you apply
correct pull up/downs to GPIO 0, 2, 15, CH_PD, RST.
On May 19, 2015 22:24, "Markus" notifications@github.com wrote:

try this setup:

https://github.com/esp8266/Arduino#minimal-hardware-setup-for-bootloading-only
then the esp never load you code and the boot-loading shut work.


Reply to this email directly or view it on GitHub
#284 (comment).


Reply to this email directly or view it on GitHub.

@holgerlembke
Copy link
Contributor

I work with the following setup: I manually reset with first setting a jumper pulling GPIO0 down and then press and release a switch pulling RESET down. TXD/RXD and RXD/TXD connected, nothing more.

As far as I understand it, if you pull GPIO0 down your program never starts, ESP goes straight into program mode.

If you do a RESET you should at least see the boot gibberish.

@duncan-a
Copy link

When are you removing the jumper from GPIO0?

On 19 May 2015 at 21:59, holgerlembke notifications@github.com wrote:

I work with the following setup: I manually reset with first setting a
jumper pulling GPIO0 down and then press and release a switch pulling RESET
down. TXD/RXD and RXD/TXD connected, nothing more.

As far as I understand it, if you pull GPIO0 down your program never
starts, ESP goes straight into program mode.

If you do a RESET you should at least see the boot gibberish.


Reply to this email directly or view it on GitHub
#284 (comment).

@holgerlembke
Copy link
Contributor

Sometimes never... :-)

It works fine: Set jumper, upload. ESP reboots into my code after upload, make changes, press reset, upload. Repeat...

When I remove, normally I remove jumper after upload done. Due to my unsynchronized human hands,

@duncan-a
Copy link

The procedure is:

  • Connect GPIO to GND (via a pulldown) - in your case using a jumper
  • Press RESET (or toggle power) Blue LED flashes
  • Upload the code to the ESP
  • Remove the jumper
  • Press Reset (or toggle power)

There was a problem where the Flash needed to be erased using PyTools
before uploading again - but I think that has been fixed...

On 19 May 2015 at 22:05, holgerlembke notifications@github.com wrote:

Sometimes never... :-)

It works fine: Set jumper, upload. ESP reboots into my code after upload,
make changes, press reset, upload. Repeat...

Normally I remove jumper after upload done. Due to my unsynchronized human
hands,


Reply to this email directly or view it on GitHub
#284 (comment).

@holgerlembke
Copy link
Contributor

For me my method works reliable with ESP-12 & ai-thinker.

works

@kdschlosser
Copy link

use a better set of cables between whatever you are using for TTL and the ESP (and i hope it's not 5v) 3.3 volt only. i had the exact same problem. do not use a breadboard and as small or short a wire to connect from the ttl to the esp.2 wires you have to use for programming and you have to hold the GPIO0 (i think it's zero been a minute since i flashed one) to ground, it has to stay there. so ground from TTL to ESP and to the GPIO. and then tap the RST to ground, CHPD has the be pulled high, 5K should be fine, and if all else fails, shoot me a message i have a fix, but will require software. i have all the stuff necessary. I am pretty sure its the connection from the TTL to the esp is not up to snuff. took me about 8 hours of messin around before i pulled my project apart and connected it directly. sometimes i also have found that you may have to tap the RST (definition of tap: half a second 2 times usually works) to ground more than once for it to take. couldn't tell ya why just is. seems to be a timing thing on how long it needs to be held at ground for. and also not sure as to why and not sure if this is the IDE but the auto reset work on my 2 dollar ESP01's things actually reboot into terminal mode without even having to disconnect the GPIO

@igrr igrr closed this as completed Sep 30, 2015
@aaroniscrazy
Copy link

A little late but thank you. I managed to brick it by uploading some code that made some pins used for an input. By taking gpio0 to low I was able to reset it with esptool.py erase_flash

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants