Troubleshooting

Troubleshooting

Checking software

To get latest software, try git pull --recurse-submodules=yes.

To check nothing is out of date, look at output of git status. You can also test inside the esp-idf subdirectory cd esp-idf; git status.

Power Problems

• If flashing randomly fails, or nothing boots, then you probably have power stability problems. Hard power cycling (switching the power switch off and on) temporarily fixes this. The permanent fix is to add a capacitor on the 3.3V/GND power rails, come and see an organiser and we have some.

Assertion Failure / Crashes

There's currently an odd issue with a lot of boards crashing shortly after startup:

I (10980) mqttservice: Pu/esp-idf/components/freertos/./queue.c:1301 (xQueueGiveFromISR)- assert failed!
abort() was called at PC 0x4008325e
Guru Meditation Error: Core  1 panic'ed (abort)

Not all enviroments do this, but some do. This is a known software issue that we are working on!

Other Crashes

When esp-idf crashes ("guru meditation error") you get a dump like this:

Guru Meditation Error of type StoreProhibited occurred on core  0. Exception was unhandled.
Register dump:
PC      : 0x40106802  
PS      : 0x00060030  
A0      : 0x800d1001  
A1      : 0x3ffbab00  
A2      : 0x00000000  
A3      : 0x00000000  
A4      : 0x00060023  
A5      : 0x3ffb93bc  
A6      : 0x00000000  
A7      : 0x00000001  
A8      : 0x800836f9  
A9      : 0x3ffbba60  
A10     : 0x00000003  
A11     : 0x00060023  
A12     : 0x00060023  
A13     : 0x3ffbba60  
A14     : 0x00000003  
A15     : 0x00060023  
SAR     : 0x00000000  
EXCCAUSE: 0x0000001d  
EXCVADDR: 0x00000000  
LBEG    : 0x00000000  
LEND    : 0x00000000  
LCOUNT  : 0x00000000  

Backtrace: 0x40106802:0x3ffbab00 0x400d1001:0x3ffbab30

This dump includes the registers at the time the crash happened, and a "backtrace" of function calls leading up to that crash.

Some particularly useful details in the above:

• type StoreProhibited == type of exception. LoadProhibited = can't read this mem, StoreProhibited = can't write this mem, IllegalInstruction == CPU went to run something that wasn't valid code, plus others.
• PC - program counter == address where things went wrong
• EXCVADDR - for LoadProhibited or StoreProhibited, this is the address that the CPU tried to read or write. In the example above, 0x00000000 indicates a "null pointer" was written to.

Using addr2line

The "addr2line" tool takes CPU code addresses (PC, backtrace) and returns the line of source code where this code came from:

$ xtensa-esp32-elf-addr2line -e build/app-template.elf 
0x40106802
/home/gus/dev/lca2017/esp32-iotuz/main/./main.cpp:24
0x40106802
/home/gus/dev/lca2017/esp32-iotuz/main/./main.cpp:24
0x400d1001
/home/gus/dev/lca2017/esp32-iotuz/esp-idf/components/esp32/./cpu_start.c:264

Run xtensa-esp32-elfaddr2line -e and pass in the .elf file for your project (in the build directory.

Copy-paste code addresses (PC, or individual parts of the backtrace) from the stack dump into the addr2line session. Unfortunately, each address must be on a separate line.

addr2line will give you a line of code, or ????? if it doesn't know where this came from.

For the backtrace, the trace goes left-to-right from inner to outer stack frame. The addresses are the "return" addresses, so they are the address of the next line of code after each function call.