Cannot get esp32_exception_decoder to work

Development Platforms
1

I am using Platformio Core 6.1.11 on a Mac. Very rarely, the esp32 code I am debugging crashes and I would like to use the exception decoder to understand the reasons of the crash.
I added “monitor_filters = esp32_exception_decoder” to the platformio.ini file but I do not get any decoding analysis of the crash. I cannot work out what is missing or I am doing wrong.
I did use this feature before in another project and it did work…
Can anybody please give me some help?

Here is my platformio.ini file:

[env:esp32doit-devkit-v1]
platform = espressif32
board = esp32doit-devkit-v1
framework = arduino
monitor_speed = 115200

lib_deps = 
    fastled/FastLED
    ArduinoJson
    https://github.com/Links2004/arduinoWebSockets.git
    paulstoffregen/Time@^1.6.1
    arduino-libraries/NTPClient@^3.1.0
    https://github.com/me-no-dev/ESPAsyncWebServer.git
    ayushsharma82/AsyncElegantOTA@^2.2.7
    robtillaart/PCF8575@^0.1.6
    robtillaart/SHT31@^0.3.6
    robtillaart/TCA9548@^0.1.2
    https://github.com/Atlas-Scientific/Ezo_I2c_lib.git
build_flags = 
    -D CORE_DEBUG_LEVEL=0
board_build.partitions = partitions.csv
monitor_filters = esp32_exception_decoder

And this is the output I get when the crash occurs:

2024-01-03 12:18:00	Guru Meditation Error: Core  1 panic'ed (Cache disabled but cached memory region accessed). 
2024-01-03 12:18:00	
2024-01-03 12:18:00	Core  1 register dump:
2024-01-03 12:18:00	PC      : 0x400ed148  PS      : 0x00060035  A0      : 0x800814d2  A1      : 0x3ffbf55c  
2024-01-03 12:18:00	A2      : 0x3ffc4210  A3      : 0x00000000  A4      : 0x00060023  A5      : 0x80000000  
2024-01-03 12:18:00	A6      : 0x007bf608  A7      : 0x003fffff  A8      : 0x80081479  A9      : 0x00000000  
2024-01-03 12:18:00	A10     : 0x00000000  A11     : 0x00000000  A12     : 0x0000001a  A13     : 0x80000000  
2024-01-03 12:18:00	A14     : 0x00000002  A15     : 0x3ffc4148  SAR     : 0x00000020  EXCCAUSE: 0x00000007  
2024-01-03 12:18:00	EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000  
2024-01-03 12:18:00	
2024-01-03 12:18:00	
2024-01-03 12:18:00	Backtrace: 0x400ed145:0x3ffbf55c |<-CORRUPTED
2024-01-03 12:18:00	
2024-01-03 12:18:00	
2024-01-03 12:18:00	
2024-01-03 12:18:00	
2024-01-03 12:18:00	ELF file SHA256: 553661430b3ebb5d
2024-01-03 12:18:00	
2024-01-03 12:18:00	Rebooting...
2024-01-03 12:18:00	ets Jul 29 2019 12:21:46
2024-01-03 12:18:00	
2024-01-03 12:18:00	rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
2024-01-03 12:18:00	configsip: 0, SPIWP:0xee
2024-01-03 12:18:00	clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
2024-01-03 12:18:00	mode:DIO, clock div:2
2024-01-03 12:18:00	load:0x3fff0030,len:1184
2024-01-03 12:18:00	load:0x40078000,len:13104
2024-01-03 12:18:00	load:0x40080400,len:3036
2024-01-03 12:18:00	entry 0x400805e4
2024-01-03 12:18:01	[WDT] Panic (hardware watchdog) reset

Partitions do include a “coredump” area:

#Name,      Type,   SubType,    Offset,       Size
nvs,        data,   nvs,        0x9000,       16K
phy_init,   data,   phy,        0xD000,       4K
otadata,    data,   ota,        0xE000,       8K
app0,       app,    ota_0,     0x10000,       1920K
app1,       app,    ota_1,    0x1F0000,       1920K
config,     data,   spiffs,   0x3D0000,       32K
webif,      data,   spiffs,   0x3D8000,       96K
coredump,   data,   coredump, 0x3F0000,       64K
2

To make the exception decoder work it needs debug informations.
For this you need to change the build type to debug instead of release.
Add build_type = debug to your platformio.ini.

1 Like
3

Nothing worked for me too. I had to write my own decoder in DotNetCore. Works perfectly in windows, should also work in linux and mac with dotnetcore installed.

Here is the git.

4

“Nothing worked”? Backtrace decoding works perfectly fine.

grafik
grafik1920×1040 102 KB

1 Like
5

Likewise. When I last looked at the exception monitor (to replace it, alas) it was just some python that built a shell wrapper around addr2line whidch part of binutils (maybe gdb) that looks for “hexy” numbers (0x400ed148 and maybe even 400ed148 in some contexts) and gropes the symbol table to see if it can be resolved between _start and _end (with some exceptions for shared libraries and such, but insid the .text section) and associate it with debugger line informatino if available (yay!) or the entry point of a function (it has a global symbol - the branch targets and such are locals) and then an opcode offset from that. Even if you have to disassemble he whole binary and just copy/paste symbols into search, it’s still WAY easier than doing this by hand. There’s some extra magic for stack frame unwinding and exception decoding, but these are all tricks the GNU tools know how to do. But you should be able to run that same info2line and see the output, confirm it’s looking in the right place for the symbol table (at foo.elf and not foo.bin), see any error that’s being eaten by monitor, etc.

I’m not even certain why I wound up replacing it. I think it was because it wanted to be a read-only view of the board and I wanted to interact with the device over the monitor or something. It was a long time ago.

Pro tip: you can resolve the global symbols even without the board running if you still have the executable.

$ xtensa-esp32-elf-gdb  .pio/build/generic/firmware.elf
(gdb) disassemble app_main
Dump of assembler code for function app_main():
   0x400fda1c <+0>:	entry	a1, 48
   0x400fda1f <+3>:	l32r	a8, 0x400d1e1c <_stext+7676> (0x3ffc6464 <loopTaskWDTEnabled>)
   0x400fda22 <+6>:	movi	a9, 0
   0x400fda25 <+9>:	s8i	a9, a8, 0

or backwards

(gdb) info line *0x400fda1c
Line 56 of ".platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp" starts at address 0x400fda1c <app_main()> and ends at 0x400fda1f <app_main()+3>.
(gdb) info line *0x400fda3f
**Line 71** of ".platformio/packages/framework-arduinoespressif32/cores/esp32/**main.cpp**: starts at address 0x400fda2b <app_main()+15> and ends at 0x400fda42 <app_main()+38>.

I have no idea why it requires the ‘*’, exactly like C or assembler doesn’t. :person_shrugging:

Anyway, there are some debugging tips for anyone else trying to debug this or replace/augment it.