【问题标题】:Analyze ESP32 backtrace on NodeMCU分析 NodeMCU 上的 ESP32 回溯
【发布时间】:2021-04-14 05:57:21
【问题描述】:

我正在调试 NodeMCU Lua 固件的 dev-esp32 分支上的一些崩溃。你们其他 NodeMCU 开发人员如何分析回溯?

在正常的 ESP32 开发期间,idf 监视器处理回溯解码。我尝试在我的 NodeMCU 构建中使用 IDF 监视器(不成功)。我也试过https://github.com/me-no-dev/EspExceptionDecoder,但没有成功。

在我深入研究这个问题之前,我想我会检查其他人是如何处理它的。

下面是我尝试解码的输出类型示例。

Guru Meditation Error: Core  1 panic'ed (StoreProhibited). Exception was unhandled.
Core 1 register dump:
PC      : 0x4000c3f5  PS      : 0x00060430  A0      : 0x800ed304  A1      : 0x3ffc3fe0  
A2      : 0x80171ba1  A3      : 0x3ffc4292  A4      : 0x00000001  A5      : 0x3fe1a9a4  
A6      : 0x7ff00000  A7      : 0x000e6c6e  A8      : 0x00000000  A9      : 0x80171ba1  
A10     : 0x0000002d  A11     : 0x00000000  A12     : 0x3ffc9690  A13     : 0x00000010  
A14     : 0x00000001  A15     : 0x3ffc4640  SAR     : 0x00000004  EXCCAUSE: 0x0000001d  
EXCVADDR: 0x80171ba1  LBEG    : 0x400029ac  LEND    : 0x400029cb  LCOUNT  : 0x00000000  

ELF file SHA256: b809d167629a125c85da3f679dd782ec6df740657c8d4ef4df56d7eea784abcd

Backtrace: 0x4000c3f5:0x3ffc3fe0 0x400ed301:0x3ffc4000 0x400e2c8a:0x3ffc4030 0x400df6bd:0x3ffc4340 0x4013bfde:0x3ffc4400 0x4013dff9:0x3ffc4440 0x40137588:0x3ffc4460 0x4016ff04:0x3ffc4480 0x4013d8d7:0x3ffc44b0 0x4013ccdd:0x3ffc44f0 0x4013d9ae:0x3ffc4540 0x4013db89:0x3ffc4560 0x4013d1f5:0x3ffc4580 0x4013da96:0x3ffc4600 0x4013e6a2:0x3ffc4630 0x400d6e21:0x3ffc4660 0x40082c36:0x3ffc4690 0x40108137:0x3ffc46d0 0x40110043:0x3ffc4730 0x401100a2:0x3ffc4750 0x4011014e:0x3ffc4770 0x4010dc8e:0x3ffc4790 0x4008ec46:0x3ffc47b0

有关解码器尝试的其他信息

对于 EspExceptionDecoder 尝试,我将崩溃输出保存在名为 backtrace 的文件中。然后我按如下方式调用解码器,导致解析器错误(确认路径正确)。

$ shasum -a 256 ../konnected-pro/build/nodemcu-firmware/build/NodeMCU.elf 
fa399df026e014cc988df430b22c58da9a9159cea5aaca9f19f67dc67c339619  ../konnected-pro/build/nodemcu-firmware/build/NodeMCU.elf
$ ./decoder.py -e ../konnected-pro/build/nodemcu-firmware/build/NodeMCU.elf -t ~/.espressif/tools/xtensa-esp32-elf/esp-2019r2-8.2.0/xtensa-esp32-elf -p ESP32 ../backtrace 
ERROR: Parser not complete!

我在上面尝试过的backtrace 文件具有以下内容(注意 sha 与上面的检查相匹配)。

PANIC: unprotected error in call to Lua API (/lfs/ds18b20.lua:123: failed)
E (27032) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (27032) task_wdt:  - IDLE0 (CPU 0)
E (27032) task_wdt: Tasks currently running:
E (27032) task_wdt: CPU 0: main
E (27032) task_wdt: CPU 1: IDLE1
E (27032) task_wdt: Aborting.
abort() was called at PC 0x400d3708 on core 0

ELF file SHA256: fa399df026e014cc988df430b22c58da9a9159cea5aaca9f19f67dc67c339619

Backtrace: 0x40088cef:0x3ffb0a40 0x40089009:0x3ffb0a60 0x400d3708:0x3ffb0a80 0x4008273d:0x3ffb0aa0 0x4013715d:0x3ffbcde0 0x40138917:0x3ffbce00 0x4013857d:0x3ffbce20 0x40140aa1:0x3ffbce40 0x40137357:0x3ffbce60 0x400d4dfe:0x3ffbceb0 0x40138e6f:0x3ffbcee0 0x4013f1b9:0x3ffbcf20 0x40138f46:0x3ffbcf70 0x401408fd:0x3ffbcf90 0x400d5e6b:0x3ffbcfb0 0x400f9b81:0x3ffbcfd0 0x400fdc37:0x3ffbd000 0x400d27ab:0x3ffbd040

Rebooting...
ets Jun  8 2016 00:22:57

【问题讨论】:

  • “没有成功”?发生什么事?解码器必须有权访问原始 elf 文件
  • 对。你是如何运行解码器的,它的输出是什么?
  • 更新了帖子以包含有关我如何尝试使用解码器的详细信息。
  • @KitKlein 你解决过这个问题吗?

标签: esp32 nodemcu esp-idf


【解决方案1】:

我建议您购买一个 JTAG 适配器(例如,如果您还没有一个便宜的 ESP-Prog),将它连接到您的电路板 per instructions 并使用 gdb 进行调试。设置起来有点麻烦,但没有什么可以替代实际的调试工作流程。

【讨论】:

  • 不幸的是,在这种情况下,硬件没有暴露 JTAG 接口。
  • 好的。我怀疑 EspExceptionDecoder 想要 ESP IDF 发出的异常文本,它位于您的第一个代码块中 - Guru Meditation ErrorBacktrace: ... 行之间的所有内容(包括这些行本身)。文件“回溯”的内容似乎是跟踪来自看门狗组件的消息,该组件抱怨任务未能重置看门狗(这是重新启动的正当理由) - 但这不是 ESP IDF 异常输出。这只是看门狗在做它的工作 - 重新启动,因为它没有被重置:)
  • ESP IDF 环境包含一个名为 idf.py 的工具,它集成了与 EspExceptionDecoder 类似的解决方案。当您告诉它监视 ESP 芯片的输出时,它会检测到欺骗并内联解码堆栈跟踪,从而在异常文本之后立即生成 0x400d9db6: runGic(bool const&) at /home/.../CloudHub.cpp:276 之类的行。
猜你喜欢
  • 1970-01-01
  • 2022-06-15
  • 2017-09-13
  • 1970-01-01
  • 1970-01-01
  • 2022-10-14
  • 1970-01-01
  • 1970-01-01
  • 2020-11-17
相关资源
最近更新 更多