ESP32 C3 boot loop

[rjustice]

I have a load of identical PCB's with an ESP32-C3 on.

I'm using the factory flash tool, I'm using a mass programmer, the USB to serial chip is offboard and the unit is programmed via spring loaded pins

Most Boards flash fine, others don't, when I look at the ones that don't over the serial port I get this over and over:

Code: Select all

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0xe (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6268,len:0x2a58
ets_loader.c 78
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0xe (SPI_FAST_FLASH_BOOT)
Saved PC:0x40049a42
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6268,len:0x2a58
ets_loader.c 78

If I try and reflash it I get this:

Code: Select all

Serial port COM42
Connecting.........
Chip is ESP32-C3 (revision 3)
Features: Wi-Fi
Crystal is 40MHz
MAC: a0:76:4e:65:5b:80
Enabling default SPI flash mode...
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00007fff...
Flash will be erased from 0x00010000 to 0x00059fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Erasing flash...
Took 0.32s to erase flash block
Writing at 0x00000000... (3 %)
Writing at 0x00000400... (6 %)
Writing at 0x00000800... (9 %)

A fatal error occurred: Invalid head of packet (0x45): Possible serial noise or corruption.
CMake Error at run_serial_tool.cmake:56 (message):

The above occurs no matter what the serial port speed, and no matter what mass programmer I insert it into.

Interestingly if I set the baud speed higher it gets further before it fails.

What could be causing this?

Thanks....

[ESP_Sprite]

I'm wondering if I've seen a related issue... can you try to flash one with a tiny program (e.g. the blink example) that can finish flashing in time, reset the chip, and then try uploading again? Please report here what the results are.

[rjustice]

Thanks for the reply

I can't see how that will help me because most PCB's are fine, there is no way of knowing which one will fail. I did manage to check one prior to flashing that failed, and recieved the normal

Code: Select all

invalid header 0xfffffff

before flashing...

When i tried to flash it it failed and the below was what the serial port out put was:

Code: Select all

←[0;33m--- Using \\.\COM40 instead...←[0m
←[0;33m--- idf_monitor on \\.\COM40 115200 ---←[0m
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0xe (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6268,len:0x2a58
ets_loader.c 78
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0xe (SPI_FAST_FLASH_BOOT)
Saved PC:0x40049a42
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6268,len:0x2a58
ets_loader.c 78
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0xe (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6268,len:0x2a58
ets_loader.c 78
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0xe (SPI_FAST_FLASH_BOOT)
Saved PC:0x40049a42
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6268,len:0x2a58
ets_loader.c 78

If a ESP32-C3 fails during flashing is that it forever broken, its starting to get expensive, how do i fix this?

[ESP_Sprite]

Can you still access GPIO9? If you pull that down and reset the C3, does that fix the issue?

[rjustice]

WE still have the same problem and are having to bin about 1 in 10 boards, this is no good for any sort of production, is there a way to raise the priority of this?

Could someone explain what causes the following errors?

ESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x1 (POWERON),boot:0xe (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6268,len:0x2a58
ets_loader.c 78
ESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0xe (SPI_FAST_FLASH_BOOT)
Saved PC:0x40049a42
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6268,len:0x2a58
ets_loader.c 78
ESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021

[ESP_Sprite]

Can you still access GPIO9? If you pull that down and reset the C3, does that fix the issue?

[rjustice]

So to calrify, you suggest holding GPIO9 low then performing a reset of the mcu? I.e. instead of the DTR and RTR lines putting the unit into boot mode on the programmer you suggest I do it manually?

I will have to try that Monday.

Here is the reset pin on the board getting flashed and the RTR and DTR setup on the mass programmer.

programmer setup.png (15.34 KiB) Viewed 5342 times

May I ask what your thoughts are as to why doing this manually would make any difference? Why would some boards work and not others?

Are there any other pins that will affect behavior at boot I should check?

Notice in the previous posts above that the boards do start to flash (so must be in boot mode) then drop out stating serial communication as an issue.

I'm trying to understand what is happening here, is the unit partially getting flashed and then failing and then going into the boot loop as above?

What settings should I have the SPI flash access set to in menuconfig? its the ESP32-C3FH4 with the embedded 4mb of flash?

Many questions. We really need to get to the bottom of this.

Many Thanks for your help.

[ESP_Sprite]

Ah, never mind, I thought you used the USB-serial-JTAG converter; if you're using an UART to program the chip, my advise is not applicable.

In that case, I don't have specific advice. Suggest you check the power rails, if the UART signals look good, etc, perhaps there's an issue there. You could also try to swap parts between a good and bad board; see if you can isolate the issue to one component.