ESP32 c3 wdt reboot fail (IDFGH-6051) #7734
Comments
|
invalid header: 0xffffff7f |
github-actions
bot
changed the title
|
@u-tec-com Thanks for reporting. Would you please help provide more details as suggested in the issue template? Information like elf, sdk configuration, backtrace, log outputs, commit ID, hardware and etc. would help us debug further. Thanks. |
|
Thanks for reporting, would you please help share if more details for the issue? Thanks. |
|
@Alvin1Zhang I had similar issue on a esp32-wroom-32e module: I couldn't resolve the issue (cannot reprogram the module any more) and I cannot reproduce the issue on other devices, then I just throw away that module. |
|
I face the exact same issue as @u-tec-com, with same symptoms: We also power our ESP32 C3 on battery while trying to minimize consumption by user the Power Management module with the following configuration: I don't know what has initially triggered the watchdog, but after running normally during about a day, the ESP32 C3 is now in a reboot (RTCWDT_RTC_RESET) loop. If I manually reset the ESP32 C3, it restarts normally though. As a workaround, is there a way to configure the watchdog to act as a normal reset (like if we reset the ESP32 C3 manually), waiting for this problem to be solved? FYI, we use a ESP32-C3-WROOM-02 module, with ESP-IDF master branch. |
|
The issue has just occurred a second time on the same esp32c3 after a few days where it was working just fine. |
|
Hi, @bbinet , when first-stage-bootloader finishes executing and then loads Second stage bootloader from the flash, it will verify Second stage bootloader's header, and if it fails, it will prompt “invalid header: ...”, as you have encountered. This error is usually caused by reading the wrong data from the flash, based on the above information this is difficult to reproduce, I suspect the problem is on the flash side, can you reproduce the above failure with USB powered? For software, I am curious about if you have been stuck in the reset caused by "invalid header: 0xffffff7f", the reset reason should be |
|
One more question, have you enabled flash encryption ? @bbinet |
|
Thank you @esp-wzh for your support. No, flash encryption is not enabled. I don't know why I get The esp32c3 restarts normally only when I manually reset the esp32c3 through the EN pin: how do the RTCWDT_RTC_RESET compares to a manual EN pin reset (what are the differences)? Regarding configuring EFUSE_FLASH_TPUW in eFuse, which value should I set? And could you explain how to proceed to write to the eFuse? Also, I will try to power my esp32c3 board from USB during a few days, and see if I can reproduce the issue. |
|
@bbinet thanks for the reply! (Considering these I don't think burn EFUSE_FLASH_TPUW is effective for this problem, please ignore this suggestion) |
|
@esp-wzh Ok so if POWERON_RESET re-power the FLASH and fixes the issue, is there a way to configure RTCWDT_RTC_RESET to do the same and re-power the FLASH too? For the moment we encounter this issue with a single esp32c3 (but we are in a prototype phase so we have tested only 2 of them). |
|
@bbinet, Sorry it doesn't support re-power FLASH by watchdog because FLASH is independent of esp32c3 chip. |
|
I am experiencing same issue on my M5Stack Stamp-C3 board. |
|
Hi, @Mosher23 , Thanks for your feedback! |
|
Hello @esp-wzh, |
|
Judging from your log, it is because a bin that does not meet the requirements of the ESP Firmware Image Format, or it is downloaded to the wrong location in FLASH. |
Could you give some hints on how to erase it? |
|
Thank you! `esptool.py erase_flash A fatal error occurred: Failed to write to target RAM (result was 01070000: Operation timed out)` |
|
But it works fine on my side... It's so weird, maybe there is a problem with the boot mode switching circuit of your dev-board, do you have any other boards encountering these problems? @Mosher23 |
|
@esp-wzh I have zero problems with other boards. But it is also my first C3 board. |
|
I've met 2 times this issue.
1st time
Same log output as @u-tec-com, unbricked with a manual reset. 2nd time
This time the power is properly supplied. I didn't unbrick it successfully with a manual reset (via Then I tried to read the efuse and it unbricked. |
|
Hi~@HiFiPhile, I think the first thing to do is to confirm whether the data in the flash is still correct For the first times, whether the boot is successful after powering on again? If it always prompts invalid header error. You can try to use the You can also use the same method to check the chip with flash encryption enabled, but you need to use the |
The flash data is correct. The first time I recovered it with a manual reset. Yesterday it happened again with my 2nd board, this time a reset with idf_monitor recovered it. Unfortunately I didn't activate log to file so I don't know the cause of reset. I'm going to open the shield of ESP32-C3-WROOM and hook a logic analyzer into SPI flash and wait next failure, hope I don't need to wait 2 weeks:
|
|
Hi @u-tec-com @bbinet , Have you seen anymore this issue ? I've set up logic analyzer & monitor log to wait the issue to trigger. I've only seen 3 times this issue in 4 months, I hope this time it won't take too much time. |
|
@HiFiPhile Since I've changed my code to deep sleep most of the time, I've not seen the issue anymore. |
|
on my side, this issue is fixed since I've set CONFIG_ESP_SLEEP_POWER_DOWN_FLASH=n |
espressif-bot
added
Resolution: Done
|
Thanks for sharing the updates, feel free to reopen. |
|
I've experienced similar boot fail behavior, BUT it happened at random power-up events. The product is mains powered. Flipped the switch a number of times and then boot failed with: The above happened quite repeatably (and very frustratingly) with 1 fail every 10 to 15 power-cycles. After trying various things (including the above suggestion of Interestingly though: I noticed in my sdkconfig file: AND Under # Deprecated options for backward compatibility: From previous bad experiences, I don't edit the sdkconfig directly any more, but stick to I'm hoping that the "dio" mode overrides the QIO=y options. |
|
I just observed "invalid header: 0xffffff7f" once. ESP-ROM:esp32c3-api1-20210207 |
|
@AxelLin, Thanks for report. The reason for this problem is that you use USB-Serial-JTAG to perform a reset at the moment of the Flash erase operation. USB reset will not re-power on Flash (which is different from Power on reset when you use UART console to reset the chip), resulting in that the Flash state is not ready when the chip accesses Flash after reset. I think this kind of problem only exists when you use the USB console to debug, of course we will fix this problem on future chips. If you do not want to see these errors print, you can program eFuse
|
|
@esp-wzh Hello, I have some confusions about the Image taken from the ESP32-C3 datasheet page 119:
|
|
I'm having the same To reproduce the issue I just need to restart the esp32 module a couple of times (sometimes 4, sometimes more than 20) using the Once the issue start I can't exit from that state until a power off / power on cycle, the Here I have some logs of the issue: Should I try to program the |
|
Hi~ @ordonezt
If and only if the configuration value is equal to 15, the delay time is 30ms.
Default time is zero, the default value is 0, which means no waiting, because tsome software initialization has already taken up about 5ms.
Both tPWD and tVSL violations can trigger this problem. On C3, I am more worried about tPWD violation, because as discussed in this thread, the reference design has a capacitor on VDD_SPI, which may cause the Flash chip power not drop below Vpwd voltage quickly when the chip is reset. When the chip needs to be reset, the low level time of CHIP_EN can be increased to avoid this problem. |
|
@esp-wzh thank you so much for the clarification and quick response!
Do you have any estimated value on the minimum
Do you have any recommendations on the value to program to In the first set of pictures you can see the moment were the error ocurrs. The low level time of Oscilloscope: The second set of pictures is from a reset during the invalid header error state. The low level time of Oscilloscope: |
Theoretically, no configuration is required, but if your application does not mind the startup time, the larger the better (the maximum is 30ms)
Does it mean that even if CHIP_EN lasts for 1.5 seconds, the error may still occur? This doesn't make sense.
Can you try to capture the voltage waveform on the VDD_SPI pin (with CHIP_EN pin) when the error occurs? |
Yes
Sure, here is a capture of And here is the logic analyzer capture of the same pulse And here I have a capture of a
|
|
Does your hardware design have a power supply VDD_SPI PIN? Or is the VDD_SPI pin used as a GPIO? It seems that the FLASH chip is not powered off and up when the chip is reset. ESP32-C3FH4 has a built-in Flash, and when the chip is reset, it will also re-power on VDD_SPI to reset the Flash chip (SPI FLASH chip does not have a reset pin or SPI command for reset, and can only be reset by re-powering on. Usually, when the Flash chip is accidentally interrupted during a write operation, it needs to be reset to continue accessing) |
espressif-bot
added
Status: Reviewing
|
VDD_SPI is connected to a 3.3V power supply in my design, should I remove R220 to allow the flash chip to reset when a CHIP_EN reset pulse is performed? If I remove R220, will the internal flash still work? I don't have an external flash in my design. |
Yes, you can remove it, the LDO regulator of the esp32c3 will power the flash chip inside the package. |
|
Thanks @esp-wzh! I can't reproduce the problem anymore after removing R220 🙌 Unfortunately we have several boards already produced and it would be very difficult to do the rework on all of them.
Is there anything we can do to avoid this accidental interrupt? I'm thinking of putting the ESP32-C3 in sleep mode before applying a CHIP_EN reset. |
|
@esp-wzh deep sleep approach is not working, I'm still able to reproduce the invalid header problem.
This is my procedure:
This is the log: |
|
Also I'm reproducing the issue every time the deep sleep timer ends |
@ordonezt In this figure, notice that the external power supply voltage of VDD_SPI is 3.8V, which exceeds the Operating Range limits in the datasheet. I suspect this problem may be related to the voltage. Can the voltage be lowered to within 3.6V for testing?
|
espressif-bot
added
Status: Done
use C3 in battery/low power product. The wdt reboot system in some situation. But reboot fail
The text was updated successfully, but these errors were encountered: