ESP32 PICO D4 - Bootloader reset? - Flash error

[Martin1454]

All logs are suggesting its something with UART (not stable connection, during flashing) or IO12 is not grounded properly, but i may missing something. Are there any pullup on TX/RX, which may help?

No pullup - I just tried to add one, but no change. And that would not explain why I was able to flash multiple times before I flashed the prototype firmware

Worth mentioning that there have been no HW changes between our hello world sketch and the prototype firmware.

[ESP_Sprite]

Worth mentioning that there have been no HW changes between our hello world sketch and the prototype firmware.

Yeah - I'm confused by that, to my knowledge there is nothing that's in flash that can affect the bootloader like we're seeing here.

[Martin1454]

I tried to use the ESPtool to read flash status and get "flash status: 0x2000",

But writing to the flash using the tool I get 0xFFFF.
I also tried the ESP download tool without success.

I tried adding pull up to TX / RX, and have tried to add extra pull down on MTDI.

I'm gonna try to hook up an scope to the SPI pins for the flash and check for activity, and I've ordered an ESP32 PICO board that I will try to flash my firmware to, to check if it could be an hardware issue.

Is there a way to use another ESP32 to connect to the SPI pins and dump the flash of the pico?

Let me know if you have other guess / things to test.

[Martin1454]

To make sure it was not an HW issue, I bought an ESP32 PICO kit V4.

Flashing the same firmware triggers an similar result - but not completely the same.
After uploading the problematic firmware to the PICO kit, then the first few messages after soft reset is:

Code: Select all

rst:0x8 (TG1WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:12776
load:0x40080400,len:3032
entry 0x400805e4
<Info>    ESP32ADC1 - ADC ref: eFuse Vref 1��&&jY5
␓9{�C��8@�v���␆�e#�t@B��{$��$Co�H�KPQBƌ��{���l�#ets Jun  8 2016 00:22:57

Then after a few of these messages, it goes back to:

Code: Select all

rst:0x7 (TG0WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

So there is some issue with the project that causes it to not load from the SPI.....

But a big diffrence between the PICO KIT and my custom PCB, is that I get to flash new firmware to PICO kit even after the bad firmware. So there is part SW issue, but there should also be a HW issue since I'm not allowed to flash new firmware on my custom PCB after the bad firmware.

[ESP_Sprite]

Any chance you can share that mysterious problematic firmware (plus tell us exactly what environment it needs to compile)? It's really odd that it crashes in that way.

[Martin1454]

Tested using JTAG from ESP-PROG to flash a "bricked PCB - No sucess....

Code: Select all

Error: timed out while waiting for target halted
Error: xtensa_wait_algorithm: not halted 0, pc 0x40090084, ps 0x60025
Error: Failed to wait algorithm (-302)!
Error: Algorithm run failed (-302)!
Error: Too many flash mappings 10418076! Must be 2.
Warn : Failed to get flash mappings (-4)!
Error: Target is already running an algorithm
Error: Failed to start algorithm (-4)!
Error: Failed to get flash size!
Error: Target is already running an algorithm
Error: Failed to start algorithm (-4)!
Error: Failed to get flash size!
Error: Failed to probe flash, size 0 KB
Error: auto_probe failed
Error: Failed to find bank 'esp32.cpu0.flash'!

*** [upload] Error 1

[Martin1454]

Success! – We found out what line in our code caused the issue.

In an old prototype before I worked on the project, the team used a second serial port for some debugging.

This ‘serial 2 begin’ line of code tried to use U2TXD and U2RXD which is IO16 & IO17.

IO16 and IO17 is used in the ESP32 PICO D4 for the internal flash for /CS and DO, where in the the old prototype with the wroom module it uses CMD and SD0 instead. So this serial port is block our access to the internal flash. Disabling this made it possible for us to flash the firmware on a new PCB

[ESP_Sprite]

That is tricky. That may also be why your flash died: the UART may have put some signals on there that managed to change some configuration registers in the flash chip itself, making it inaccessible. Glad to hear you found it!