ESP32 Hangs after OTA Update

[sidwarkd]

After applying an OTA update my ESP32 WROOM-32D no longer boots. When I look at the serial output I see that it makes it to the "App cpu up" line but never beyond that which makes me think this is in the bootloader. The WDT then kicks in and resets it. It is stuck in this loop forever. I have devices in the field that I'm afraid I will put in this state if I release an OTA update. Here is the serial output which loops over and over

Code: Select all

ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (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:6908
ho 0 tail 12 room 4
load:0x40078000,len:14308
load:0x40080400,len:3716
0x40080400: _init at ??:?

entry 0x40080680
I (29) boot: ESP-IDF v4.3.1 2nd stage bootloader
I (29) boot: compile time 07:01:12
I (29) boot: chip revision: 1
I (32) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (39) boot.esp32: SPI Speed      : 40MHz
I (43) boot.esp32: SPI Mode       : DIO
I (48) boot.esp32: SPI Flash Size : 4MB
I (52) boot: Enabling RNG early entropy source...
I (58) boot: Partition Table:
I (61) boot: ## Label            Usage          Type ST Offset   Length
I (69) boot:  0 nvs              WiFi data        01 02 00009000 00004000
I (76) boot:  1 otadata          OTA data         01 00 0000d000 00002000
I (84) boot:  2 ota_0            OTA app          00 10 00010000 001b0000
I (91) boot:  3 ota_1            OTA app          00 11 001c0000 001b0000
I (99) boot:  4 storage          Unknown data     01 82 00370000 00080000
I (106) boot: End of partition table
I (110) boot_comm: chip revision: 1, min. application chip revision: 0
I (117) esp_image: segment 0: paddr=001c0020 vaddr=3f400020 size=29e90h (171664) map
I (188) esp_image: segment 1: paddr=001e9eb8 vaddr=3ffbdb60 size=04a94h ( 19092) load
I (196) esp_image: segment 2: paddr=001ee954 vaddr=40080000 size=016c4h (  5828) load
I (199) esp_image: segment 3: paddr=001f0020 vaddr=400d0020 size=bbc64h (769124) map
I (480) esp_image: segment 4: paddr=002abc8c vaddr=400816c4 size=1d458h (119896) load
I (530) esp_image: segment 5: paddr=002c90ec vaddr=400c0000 size=00064h (   100) load
I (530) esp_image: segment 6: paddr=002c9158 vaddr=50000000 size=00010h (    16) load
I (551) boot: Loaded app from partition at offset 0x1c0000
I (551) boot: Disabling RNG early entropy source...
I (562) cpu_start: Pro cpu up.
I (562) cpu_start: Starting app cpu, entry point is 0x40081610
0x40081610: call_start_cpu1 at /opt/esp/idf/components/esp_system/port/cpu_start.c:141

I (0) cpu_start: App cpu up.

Some similar issues I've found on this:
https://github.com/espressif/esp-idf/issues/7926
viewtopic.php?f=13&t=11963#
https://esp32.com/viewtopic.php?t=19160#

I don't think this is the same as the Github issue as my bootloader isn't from the commit window mentioned. Is there anything I can do to prevent my devices in field from bricking as far as the customer is concerned?

[ESP_Sprite]

Sorry, I can't help with the issue itself, but the app cpu only gets started when the application starts running; as such the hang+reset itself isn't happening in the bootloader.

[sidwarkd]

@ESP_Sprite Thanks for pointing that out. You made me dig deeper into this and I have a question. The boot log shows "Starting app cpu, entry point is 0x40081610". Is there any way to correlate that address to a physical location or is it a dynamic virtual address? I know the app cpu is starting but my very first line of code is a print that never shows so I'm trying to figure out exactly why the app spins until the WDT resets the device.

[ESP_Sprite]

You can use addr2line, or if you use 'idf.py monitor' as your terminal it'll decode it for you.