The notorious "flash read err, 1000" - with a twist

[u063096]

I have been skimming the net in the past days to find a solution to my issue to no avail.

I got an ESP32 DevkitC V4 board for development that ran for months without any problem. But some weeks ago it started to not boot properly on RESET pressed, but fell into the notorious

Code: Select all

rst:0x10 (RTCWDT_RTC_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

boot loop.

I have an ESP-prog attached to it that I always have used to flash firmwares. If I will press RESET on the ESP-prog, the ESP32 does react as expected, the boot is continuing without an issue. But as soon as I will use the RESET button on the DevkitC board, the boot loop will start over.

For the time being I can continue resetting the board via the ESP-prog, but that option of course will not be available with the boards in the field....

I already checked the power supply (a 5V/2A one) and wiring and found no fault there.

Any hints what may be happening here and on how to solve it?

[WiFive]

What if you use a jumper to ground on reset instead of the button?

[u063096]

Nothing different, unfortunately.

[chegewara]

https://github.com/espressif/esptool/wi ... t-messages

This fatal error indicates that the bootloader tried to read the software bootloader header at address 0x1000 but failed to read valid data. Possible reasons for this include:

[*] There isn't actually a bootloader at offset 0x1000 (maybe the bootloader was flashed to the wrong offset by mistake, or the flash has been erased and no bootloader has been flashed yet.)
[*] Physical problem with the connection to the flash chip, or flash chip power.
[*] Boot mode accidentally set to HSPI_FLASH_BOOT, which uses different SPI flash pins. Check GPIO2 (see above).
VDDSDIO has been enabled at 1.8V (due to MTDI/GPIO12, see above), but this flash chip requires 3.3V so it's browning out.
[*] Flash encryption is enabled but the bootloader is plaintext. Alternatively, flash encryption is disabled but the bootloader is encrypted ciphertext.

It also looks like some hardware issue (soldering, faulty button etc).

[Michalpu]

Faulty button could be point here I think I have simmiliar thing

[u063096]

Faulty button could be point here I think I have simmiliar thing

But should not touching EN with a GND wire work in that case?

[u063096]

https://github.com/espressif/esptool/wi ... t-messages

This fatal error indicates that the bootloader tried to read the software bootloader header at address 0x1000 but failed to read valid data. Possible reasons for this include:

[*] There isn't actually a bootloader at offset 0x1000 (maybe the bootloader was flashed to the wrong offset by mistake, or the flash has been erased and no bootloader has been flashed yet.)
[*] Physical problem with the connection to the flash chip, or flash chip power.
[*] Boot mode accidentally set to HSPI_FLASH_BOOT, which uses different SPI flash pins. Check GPIO2 (see above).
VDDSDIO has been enabled at 1.8V (due to MTDI/GPIO12, see above), but this flash chip requires 3.3V so it's browning out.
[*] Flash encryption is enabled but the bootloader is plaintext. Alternatively, flash encryption is disabled but the bootloader is encrypted ciphertext.

I think I sorted out all these. No encryption, fuses all set okay, and if the flash was faulty, the JTAG boot would fail as well, right?

[u063096]

Other ideas, anyone? I am at a loss here.

[Update] I definitely can sort out power issues (brownouts or such). I now am powering the setup with my lab PSU, both 3.3V and 5V rails may suck up to 1.5A without voltage drop. The complete setup is using a mere 0.5 watts as seen on the PSU, startup current is neglegible higher.

Dang!

[u063096]

Just in case someone will encounter the same issue, here's the solution:

The ESP-prog JTAG line "TDI" is configured on GPIO12. So with the JTAG connected GPIO12 gets a defined logic level on boot from the ESP-prog. Unfortunately, on boot the GPIO12 line is controlling the flash voltage and with my board it obviously is wrong as soon as the ESP-prog is connected to it.

Removing the TDI wire to the ESP-prog brings the ESP32 back to normal.

I am still looking for a solution to tell the ESP-prog to leave the GPIO12 signal on the appropriate level.

[ESP_Sprite]

You could burn the eFuse in the ESP32 to indicate it should ignore that bootstrap pin and just use a set voltage. espefuse.py has an easy option for that, suggest you look that up if you want to go that route.