[Newbie] How to interpret an exception

[0xffff]

Hi,

In a typical exception I get a register dump and a backtrace:

Code: Select all

[2018-07-15T22:44:59.513] [ALL] USB - Guru Meditation Error of type LoadProhibited occurred on core  0. Exception was unhandled.
[2018-07-15T22:44:59.518] [ALL] USB - Register dump:
[2018-07-15T22:44:59.530] [ALL] USB - PC      : 0x401461dd  PS      : 0x00060a30  A0      : 0x8013fbd4  A1      : 0x3ffdd580
[2018-07-15T22:44:59.536] [ALL] USB - A2      : 0x3ffdd9a0  A3      : 0x00000001  A4      : 0x3f418408  A5      : 0x00000b08
[2018-07-15T22:44:59.547] [ALL] USB - A6      : 0x3f4190d4  A7      : 0xffff9400  A8      : 0x00043f41  A9      : 0x3ffdd2c0
[2018-07-15T22:44:59.558] [ALL] USB - A10     : 0x3ffba3b0  A11     : 0x00000001  A12     : 0x3f418408  A13     : 0x0000060d
[2018-07-15T22:44:59.562] [ALL] USB - A14     : 0x3f418638  A15     : 0x00000000  SAR     : 0x00000004  EXCCAUSE: 0x0000001c
[2018-07-15T22:44:59.576] [ALL] USB - EXCVADDR: 0x00043f61  LBEG    : 0x4000c46c  LEND    : 0x4000c477  LCOUNT  : 0x00000000
[2018-07-15T22:44:59.581] [ALL] USB -
[2018-07-15T22:44:59.585] [ALL] USB - Backtrace: 0x401461dd:0x3ffdd580 0x4013fbd1:0x3ffdd5a0 0x401401f5:0x3ffdd5c0 0x4014023d:0x3ffdd5e0 0x40139e17:0x3ffdd600 0x4015c8c3:0x3ffdd620 0x40138756:0x3ffdd640 0x40138f2b:0x3ffdd660

I typically use the backtrace with xtensa-esp32-elf-addr2line and the .elf file to understand the call sequence that led to the issue, but am wondering about 2 things:

1. What are the two colon-separated numbers in a backtrace signify? In the backtrace above, 0x401461dd:0x3ffdd580 maps to the to the PC and A1 values, but not sure what that really means

2. What can I learn from the register dump that may be helpful in debugging

If there is a link to help me RTFM, would appreciate it - my searches were in vain.

[ESP_Sprite]

The backtrace numbers are bits of information about the call stack, as you may know: each function call creates a so-called stack frame (the location on the stack where it stores its own temporary data) on entry and cleans it up on return. If you have a function calling a function calling a function etc, you will have multiple stack frames located under eachother on the stack: as the stack in the Xtensa grows downwards, the last function has the lowest address. The global current stack position is remembered using the stack pointer, aka SP. What you see in the backtrace are pairs of PC:SP, aka the address of the call into the next function and the stack pointer, for each stack frame. The PCs are used and decoded if you throw them in addr2line, the SP (as far as I know) is ignored.

The rest of the exception is a register dump. Most of the registers are used by your program as 'temporary values' and their contents will depend on what it was doing at that point. The only exception I know that is useful and not already decoded elsewhere in the exception or addr2line: in the case of a load/store exception, the EXCVADDR will tell you what address the CPU was trying to load from / store to.

In general, if you can, it's way easier to use the gdbstub feature combined with 'make monitor'. That will drop you in gdb as soon as a crash happens, allowing you to inspect variables as well.

[0xffff]

Very helpful. Thanks.

[ESP_Angus]

In addition to the guidance in ESP_Sprite's post, there is an explanation of the panic handler (and some of the exception causes, etc) in the documentation here:
https://docs.espressif.com/projects/esp ... rrors.html