ESP32-S3 nvs_set_blob results in watchdog trigger

rtborg
Posts: 67
Joined: Wed Oct 23, 2019 6:15 am

ESP32-S3 nvs_set_blob results in watchdog trigger

Postby rtborg » Fri Mar 17, 2023 9:47 am

Saving a large (<1K) blob into NVS results in a reset due to watchdog trigger. The problem does not appear every time the operation is performed.

Details of the application:
- Support for power management is enabled
- RTC watchdog period 9000 ms
- Task watchdog timer set for 5 sec
- NVS size: 16 KB
- Blob size: 865 bytes
- Flash speed: 80 MHz

Log from the chip when the event happens below. Any thoughts what may be causing this, and how to rectify it?

Thanks

Code: Select all

W (322607) config: Saving config to storage
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x8 (TG1WDT_SYS_RST),boot:0x29 (SPI_FAST_FLASH_BOOT)
Saved PC:0x4037aff6
0x4037aff6: _xt_context_save at C:/Users/me/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/xtensa_context.S:213

SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3810,len:0x168c
load:0x403c9700,len:0xbe0
load:0x403cc700,len:0x2e94
SHA-256 comparison failed:
Calculated: 9a60315aca05695e51d571e6d566973fe86e87ccf146e210b1ab01a815ad82ee
Expected: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Attempting to boot anyway...
entry 0x403c9900
I (47) boot: ESP-IDF v5.0-494-g490216a2ac 2nd stage bootloader
I (48) boot: compile time 09:23:35
I (48) boot: chip revision: v0.1
I (51) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (58) boot.esp32s3: Boot SPI Speed : 80MHz
I (63) boot.esp32s3: SPI Mode       : DIO
I (67) boot.esp32s3: SPI Flash Size : 8MB
W (72) boot.esp32s3: PRO CPU has been reset by WDT.
W (78) boot.esp32s3: APP CPU has been reset by WDT.
I (83) boot: Enabling RNG early entropy source...
I (89) boot: Partition Table:
I (92) boot: ## Label            Usage          Type ST Offset   Length
I (99) boot:  0 nvs              WiFi data        01 02 00009000 00004000
I (107) boot:  1 otadata          OTA data         01 00 0000d000 00002000
I (114) boot:  2 phy_init         RF data          01 01 0000f000 00001000
I (122) boot:  3 factory          factory app      00 00 00010000 00100000
I (129) boot:  4 ota_0            OTA app          00 10 00110000 00100000
I (137) boot:  5 ota_1            OTA app          00 11 00210000 00100000
I (145) boot: End of partition table
I (149) boot: Defaulting to factory image
I (154) boot_comm: chip revision: 1, min. application chip revision: 0
I (161) esp_image: segment 0: paddr=00010020 vaddr=3c030020 size=10b00h ( 68352) map
I (177) esp_image: segment 1: paddr=00020b28 vaddr=3fc92e00 size=02450h (  9296) load
I (179) esp_image: segment 2: paddr=00022f80 vaddr=40374000 size=0d098h ( 53400) load
I (194) esp_image: segment 3: paddr=00030020 vaddr=42000020 size=2feach (196268) map
I (217) esp_image: segment 4: paddr=0005fed4 vaddr=40381098 size=01d50h (  7504) load
I (224) boot: Loaded app from partition at offset 0x10000
I (224) boot: Disabling RNG early entropy source...
I (237) cpu_start: Pro cpu up.
I (237) cpu_start: Starting app cpu, entry point is 0x40375328
0x40375328: call_start_cpu1 at C:/Users/me/esp/esp-idf/components/esp_system/port/cpu_start.c:142

I (0) cpu_start: App cpu up.
I (251) cpu_start: Pro cpu start user code
I (251) cpu_start: cpu freq: 160000000 Hz
I (252) cpu_start: Application information:
I (254) cpu_start: Project name:     fuel_bug_firmware
I (260) cpu_start: App version:      c68a580-dirty
I (266) cpu_start: Compile time:     Mar 17 2023 09:23:23
I (272) cpu_start: ELF file SHA256:  145823fc085d37b8...
I (278) cpu_start: ESP-IDF:          v5.0-494-g490216a2ac
I (284) heap_init: Initializing. RAM available for dynamic allocation:
I (291) heap_init: At 3FC973A0 len 00052370 (328 KiB): D/IRAM

CKiamy
Posts: 19
Joined: Wed Nov 23, 2022 3:01 pm

Re: ESP32-S3 nvs_set_blob results in watchdog trigger

Postby CKiamy » Sat Mar 18, 2023 10:01 am

The nvs_set_blob operation is probably taking too much time, thus triggering the watchdog since it "thinks" the esp is stuck. Please provide:

1. A snippet of the code block where you see the error occuring.

2. A log file with log level set to debug or verbose mode.

3. More details of your application. Are multiple tasks triggered during this operation? Can you monitor heap and stack levels?

Who is online

Users browsing this forum: ElectricThanhTung and 104 guests