3

In a part of my sketch I put by mistake

pinMode(7,INPUT_PULLUP);

Which is dedicated pin for external flash chip (gpio7/SDIO_DATA_0/SPI_MISO) that not supposed to use for sketch. after uploading sketch now ESP is not responding to any further programming.

Could be Flash chip got corrupted due to the above mistakes?. Is it possible to recover? I already bricked two of my modules with same sketch before identifying above mistake. Sketch where working normal on Modules without above code.

When I connect to module with baud-rate 74880 chip returns

ets Jan 8 2013,rst cause:2, boot mode:(3,7)

Please check what happens when I try to upload the code upload error

Improve this question

2 Answers 2

Reset to default
1

No, you have not bricked your ESP8266 by turning on GPIO7's pullup. All that will do is provide a weak pullup on the MISO line of the flash chip, which itself will have no effect - the flash chip's SPI Data Out pin will be able to easily override that weak pullup.

You can remove the flash chip and replace it with a completely blank brand new flash chip with nothing on it and still upload new code. There is nothing in the flash chip that the ESP8266 relies on to operate.

The boot sequence of the ESP8266 is as follows:

- Start executing the bootloader from the built-in ROM
  - Read the GPIO pins to determine code execution source
  - If flash is selected then initialize flash chip and read from address 0
    - Code on flash examines partition table to find code entry point
    - Jump to code entry point
  - If UART is selected then initialize UART
    - Wait for commands over the UART and respond accordingly

The startup code (boot stage 0) is in ROM. It's impossible to "brick" that. All that is in the flash is the code that tells the ESP8266 how to find the user's code, and that gets flashed to the chip every time you reprogram it.

You can think of it like BIOS boot on a PC. In the ROM is the BIOS that tells the CPU how to read from the hard drive. Then at the start of the hard drive is the code that tells the CPU how to load the operating system. The hard drive doesn't come with that code on it - you install that along with the operating system. But the motherboard has the BIOS built into ROM which tells it how to get going and read that boot sector.

However it is possible to destroy an ESP8266 by connecting the wrong things up to it in the wrong way. It is also possible to destroy some USB chips (the CH340G in particular) by wiring things up wrong.

So chances are that if you have bricked your ESP8266 it has nothing to do with your program and everything to do with what you have wired to it.

Improve this answer
1
  • @sim son and Majenko Thanks for your efforts to address my issue. Now it is clear for me that unless I damage the chip itself it will be recoverable even some thing goes wrong and corrupted the flash. Yesterday night as a further attempt I restarted my PC hoping that the serial driver or hardware did something faulty, now I'm able to flash my modules again !!. I'm still puzzled and looking into what did the problem actually.
    – saif
    Commented Sep 30, 2019 at 7:33
0

No, your sketch can not brick the device in that way. It's the bootloader that decides after a reset/power-up whether the esp has to accept a firmware (flash button is pressed) or has to run the uploaded sketch. At that point, nothing of your sketch has yet been executed and gpios have their default configuration, which is input anyway.

Also, when a pullup is in charge, one can still apply a logic level to the respective pin. The gpio then won't see any effect from the pullup.

Improve this answer
2
  • On your first paragraph it is clear that bootloader will decide about pin status during process of sketch upload. But what happens once it has been downloaded and the sketch executed which in turn manipulates the flash memory control gpio and corrupts the bootloader on flash memory like some memory area written with '1' (eg: 1111 1111). I have no other clue since I bricked my second Lolin board also with the same sketch before identifying the above mistake (gpio7 as input)
    – saif
    Commented Sep 28, 2019 at 9:05
  • 1
    @saif The bootloader is in ROM, not flash. You cannot corrupt it. It is that ROM bootloader that looks at the IO pins and decides where to "boot" from (one option of which is "Through the UART for programming"). It is possible to remove the flash chip and replace it with a brand new completely blank one and still program it. There must be something else fundamentally wrong with what you are doing.
    – Majenko
    Commented Sep 28, 2019 at 16:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.