ESP-IDF 其他 crash log 错误整理

此篇博客用来记录 ESP-IDF crash log 除 Guru Meditation Error 之外的其他错误。

1 Brownout detector was triggered

当掉电检测器被触发时，会打印如下信息：

Brownout detector was triggered

芯片会在该打印信息结束后复位。ESP32 会默认启用内部集成的掉电检测电路，如果电源电压低于安全值，掉电检测器会触发系统复位。掉电检测器可以使用

• CONFIG_ESP32_BROWNOUT_DET
• CONFIG_ESP32_BROWNOUT_DET_LVL_SEL

这两个选项进行设置。

注：如果电源电压快速下降，则只能在控制台上看到部分打印信息。

2 Assert failed

当断言触发时，会打印如下类似信息：

syst/Users/sbstjn/Applications/esp-idf/components/freertos/queue.c:1148 (xQueueGiveFromISR)- assert failed!

这是由于 assert 检测出变量为 NULL 或者异常，从而导致 assert 失败。

3 Heap 不完整

ESP-IDF 堆的实现包含许多运行时的堆结构检查，可以在 menuconfig 中开启额外的检查 Heap Poisoning。如下图所示位置：

如果其中的某项检查失败，则会打印类似如下信息：

CORRUPT HEAP: Bad tail at 0x3ffe270a. Expected 0xbaad5678 got 0xbaac5678assertion "head != NULL" failed: file "/Users/user/esp/esp-idf/components/heap/multi_heap_poisoning.c", line 201, function: multi_heap_freeabort() was called at PC 0x400dca43 on core 0

注：更多详细信息请查阅 堆内存调试 文档。

4 Stack 粉碎

Stack 粉碎保护，可以通过 ESP-IDF 中的 CONFIG_COMPILER_STACK_CHECK_MODE 选项来开启。如下图：

如果检测到 Stack 粉碎，则会打印类似如下信息：

Stack smashing protect failure!
abort() was called at PC 0x400d2138 on core 0
Backtrace: 0x4008e6c0:0x3ffc1780 0x4008e8b7:0x3ffc17a0 0x400d2138:0x3ffc17c0 0x400e79d5:0x3ffc17e0 0x400e79a7:0x3ffc1840 0x400e79df:0x3ffc18a0 0x400e2235:0x3ffc18c0 0x400e1916:0x3ffc18f0 0x400e19cd:0x3ffc1910 0x400e1a11:0x3ffc1930 0x400e1bb2:0x3ffc1950 0x400d2c44:0x3ffc1a80

回溯信息会指明发生 Stack 粉碎的函数，建议检查函数中是否有代码访问本地数组时发生了越界。

5 Task watchdog got triggered.

这类错误为任务看门狗被触发，对应的 log 往往类似如下：

␛[0;31mE (160246) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:␛[0m
␛[0;31mE (160246) task_wdt:  - IDLE0 (CPU 0)␛[0m
␛[0;31mE (160246) task_wdt: Tasks currently running:␛[0m
␛[0;31mE (160246) task_wdt: CPU 0: user_task␛[0m
␛[0;31mE (160246) task_wdt: CPU 1: IDLE1␛[0m

这类错误往往需要着重排查上述 log 里提到的 user_task，往往是此时 user_task 一直占用着 CPU 0 而没有释放任何 CPU 资源给 task IDLE0。导致中断看门狗被触发。此时可以查看 user_task 里是否存在一直占用 CPU 资源的情况。比如在 while (1) 里一直运行各类 API 而没有添加延时（如确实是这种情况，可以在 while (1) 里适当的添加延时）。