esp32 wroom boot loop from bad powerup

seandepagnier
Posts: 3
Joined: Fri Jun 21, 2024 3:28 pm

esp32 wroom boot loop from bad powerup

Postby seandepagnier » Thu Aug 06, 2026 7:40 am

I found that it is quite easy to get an esp32 into a boot loop just by touching the power wires to a power supply enough times giving it poor power. I also found it sometimes gets into this state again possibly from falling and rising power rails.

I have the brownout detector, it just reboots over and over, and a power cycle it boots up fine.

The bootloader always works. I am wondering if anyone has seen this, and if the bootloader should be modified to either somehow powercycle the external spi flash and/or load data at a slower speed, or if an external watchdog is basically required to make the esp32 module reliable.

Code: Select all

rst:0x3 (SW_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, 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:6384
load:0x40078000,len:15916
load:0x40080400,len:3912
entry 0x40080644
I (53) boot: ESP-IDF v5.5.2-dirty 2nd stage bootloader
I (53) boot: compile time Jul 29 2026 05:00:00
I (53) boot: Multicore bootloader
I (55) boot: chip revision: v3.1
I (58) boot.esp32: SPI Speed      : 40MHz
I (62) boot.esp32: SPI Mode       : DIO
I (65) boot.esp32: SPI Flash Size : 4MB
I (69) boot: Enabling RNG early entropy source...
I (73) boot: Partition Table:
I (76) boot: ## Label            Usage          Type ST Offset   Length
I (82) boot:  0 nvs              WiFi data        01 02 00010000 00004000
I (89) boot:  1 otadata          OTA data         01 00 00014000 00002000
I (95) boot:  2 phy_init         RF data          01 01 00016000 00001000
I (102) boot:  3 factory          factory app      00 00 00020000 00100000
I (108) boot:  4 ota_0            OTA app          00 10 00120000 00140000
I (115) boot:  5 ota_1            OTA app          00 11 00260000 00140000
I (122) boot:  6 storage          Unknown data     01 83 003a0000 00040000
I (128) boot: End of partition table
I (132) boot: Defaulting to factory image
I (135) esp_image: segment 0: paddr=00020020 vaddr=3f400020 size=288c0h (166080) map
I (200) esp_image: segment 1: paddr=000488e8 vaddr=3ffb0000 size=0415ch ( 16732) load
I (206) esp_image: segment 2: paddr=0004ca4c vaddr=40080000 size=035cch ( 13772) load
I (212) esp_image: segment 3: paddr=00050020 vaddr=400d0020 size=92d74h (601460) map
I (417) esp_image: segment 4: paddr=000e2d9c vaddr=400835cc size=17fa4h ( 98212) load
I (456) esp_image: segment 5: paddr=000fad48 vaddr=50000000 size=00020h (    32) load
E (456) esp_image: Image hash failed - image is corrupt
E (457) boot: Factory app partition is not bootable
E (462) esp_image: image at 0x120000 has invalid magic byte (nothing flashed here?)
E (469) boot: OTA app partition slot 0 is not bootable
E (474) esp_image: image at 0x260000 has invalid magic byte (nothing flashed here?)
E (481) boot: OTA app partition slot 1 is not bootable
E (486) boot: No bootable app partitions in the partition table
ets Jul 29 2019 12:21:46

rst:0x3 (SW_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, 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:6384
load:0x40078000,len:15916
load:0x40080400,len:3912
entry 0x40080644
I (53) boot: ESP-IDF v5.5.2-dirty 2nd stage bootloader
I (53) boot: compile time Jul 29 2026 05:00:00
I (53) boot: Multicore bootloader
I (55) boot: chip revision: v3.1
I (58) boot.esp32: SPI Speed      : 40MHz
I (62) boot.esp32: SPI Mode       : DIO
I (65) boot.esp32: SPI Flash Size : 4MB
I (69) boot: Enabling RNG early entropy source...
I (73) boot: Partition Table:
I (76) boot: ## Label            Usage          Type ST Offset   Length
I (82) boot:  0 nvs              WiFi data        01 02 00010000 00004000
I (89) boot:  1 otadata          OTA data         01 00 00014000 00002000
I (95) boot:  2 phy_init         RF data          01 01 00016000 00001000
I (102) boot:  3 factory          factory app      00 00 00020000 00100000
I (108) boot:  4 ota_0            OTA app          00 10 00120000 00140000
I (115) boot:  5 ota_1            OTA app          00 11 00260000 00140000
I (122) boot:  6 storage          Unknown data     01 83 003a0000 00040000
I (128) boot: End of partition table
I (132) boot: Defaulting to factory image
I (135) esp_image: segment 0: paddr=00020020 vaddr=3f400020 size=288c0h (166080) map
I (200) esp_image: segment 1: paddr=000488e8 vaddr=3ffb0000 size=0415ch ( 16732) load
I (206) esp_image: segment 2: paddr=0004ca4c vaddr=40080000 size=035cch ( 13772) load
I (212) esp_image: segment 3: paddr=00050020 vaddr=400d0020 size=92d74h (601460) map
I (417) esp_image: segment 4: paddr=000e2d9c vaddr=400835cc size=17fa4h ( 98212) load
I (456) esp_image: segment 5: paddr=000fad48 vaddr=50000000 size=00020h (    32) load
E (456) esp_image: Image hash failed - image is corrupt
E (457) boot: Factory app partition is not bootable
E (462) esp_image: image at 0x120000 has invalid magic byte (nothing flashed here?)
E (469) boot: OTA app partition slot 0 is not bootable
E (474) esp_image: image at 0x260000 has invalid magic byte (nothing flashed here?)
E (481) boot: OTA app partition slot 1 is not bootable
E (486) boot: No bootable app partitions in the partition table
ets Jul 29 2019 12:21:46

boarchuz
Posts: 657
Joined: Tue Aug 21, 2018 5:28 am

Re: esp32 wroom boot loop from bad powerup

Postby boarchuz » Thu Aug 06, 2026 10:53 am

Yes a huge proportion of issues with bootup and flash are easily avoided by using a full reset. The use of software resets were a mistake in ESP-IDF imo. The argument seems to be that it allows peripherals like PWM to continue working (but who actually wants/expects this??) even though this means reinitialisation of active peripherals can cause all manner of undefined behaviour (eg. WiFi instability, or soft-bricking as in your case due to flash misconfiguration). It also allows the RTC counter to continue (but, again, do people actually want this? Or is it assumed that a reset always resets the time to 0?) and persistence of some diagnostic info in case of a crash.

First thing I do in the bootloader is check the reset reason, and do an RTC WDT reset if it's anything unexpected.

Who is online

Users browsing this forum: ChatGPT-User, Google [Bot], PerplexityBot and 1 guest