Debugging ESP32

gistfile1.txt

Re: Recipes for debugging exceptions ...
Postby ESP_Sprite » Mon Sep 26, 2016 4:03 am

You have a few methods to debug stuff like this. Three of them are:

1) You didn't know this was going to happen and just have the message you mentioned.
You can use gdb to figure out what PC and (sometimes) A0 refer to. PC is indeed the Program Counter and usually is the address of the instruction causing the exception. A0, if the compiler hasn't decide to overwrite its value with something else, is the address of the instruction calling the function that crashed. Take care that because of how the Xtensa core works, the leftmost digit of the hex number may be off and you have to manually correct it to '4'. For example, for A0 = 0x800D1234, you would want to look up 0x400D1234.

Okay, say you have a PC or A0 that seems valid, what now? You can use gdb to look up what it is. (given your source tree is in the same state as when you flashed your program. If you changed stuff in the mean time, results will be off.) Say you have address 0x400f7220, you can convert it to a source code line like such:
CODE: SELECT ALL

$ xtensa-esp32-elf-gdb ./build/testje.elf 
(gdb) info symbol 0x400f7220
app_main + 16 in section .flash.text
(gdb) list *0x400f7220
0x400f7220 is in app_main (/home/jeroen/esp8266/esp32/esp-idf-tests/main/./app_main.c:16).
11       while(1);
12   }
13   
14   void app_main() 
15   {
16       xTaskCreatePinnedToCore(unityTask, "unityTask", 4096, NULL, 5, NULL, 0);
17   }
18   

(Observe the line before the code listing: it pinpoints the problem to line 16 of app_main.c)

2) You know this is going to happen (exception is reproducible), but do not have a JTAG interface or cannot free the IO-pins for a JTAG interface.

The FreeRTOS panic handler optionally can have a small GDB stub built in. It's only good for post-mortem analysis (meaning it only kicks in after something has gone terribly wrong and you cannot really get any code running anymore after it's kicked in) but it can be extremely useful in getting a stack trace as well as inspecting the state of variables and memory to see what went wrong.

Enable it by running 'make menuconfig' and selecting 'Component config -> FreeRTOS -> Panic handler behaviour -> Invoke GDBStub'. Now run make / make flash again and reproduce the bug. On your serial terminal, you will see something like:
CODE: SELECT ALL

Guru Meditation Error of type StoreProhibited occurred on core   0. Exception was unhandled.
Register dump:
PC      :  4010677e  PS      :  00060830  A0      :  800fc22c  A1      :  3ffccdb0  
A2      :  00000000  A3      :  3ffc2a74  A4      :  00000001  A5      :  3ffccdf0  
A6      :  3ffbf444  A7      :  3ffccdf0  A8      :  00000000  A9      :  00000001  
A10     :  00000001  A11     :  0000ff00  A12     :  00000000  A13     :  00060021  
A14     :  b33fffff  A15     :  00000001  SAR     :  00000004  EXCCAUSE:  0000001d  
EXCVADDR:  00000000  LBEG    :  400014fd  LEND    :  4000150d  LCOUNT  :  fffffffe  
Entering gdb stub now.
$T0b#e6

(Observe the last two lines: it indicates the panic handler is in gdbstub mode now and expects gdb to connect to it.)

Exit your serial terminal program and invoke gdb. (Change 115200 to the baud rate you use, and /dev/ttyUSB0 to the serial port the ESP32 is connected to)
CODE: SELECT ALL

$ xtensa-esp32-elf-gdb ./build/testje.elf -b 115200 -ex 'target remote /dev/ttyUSB0'
Remote debugging using /dev/ttyUSB0
0x4010677e in test_func_20 () at /home/jeroen/esp8266/esp32/esp-idf-tests/components/tests/./test_panic.c:24
24      *i=1;
(gdb) bt
#0  0x4010677e in test_func_20 () at /home/jeroen/esp8266/esp32/esp-idf-tests/components/tests/./test_panic.c:24
#1  0x400fc22c in UnityDefaultTestRun (Func=0x40106774 <test_func_20>, FuncName=0x3f409b24 "Panic handler", FuncLineNum=20)
    at /home/jeroen/esp8266/esp32/esp-idf-tests/components/unity/./unity.c:1251
#2  0x400fbc96 in unity_run_single_test (test=0x3ffc2a74 <test_desc_20>) at /home/jeroen/esp8266/esp32/esp-idf-tests/components/unity/./unity_platform.c:58
#3  0x400fbcc1 in unity_run_single_test_by_index (index=0) at /home/jeroen/esp8266/esp32/esp-idf-tests/components/unity/./unity_platform.c:69
#4  0x400fbe2d in unity_run_menu () at /home/jeroen/esp8266/esp32/esp-idf-tests/components/unity/./unity_platform.c:140
#5  0x400fc2d7 in unityTask (pvParameters=0x0) at /home/jeroen/esp8266/esp32/esp-idf-tests/main/./app_main.c:10
(gdb) p i
$1 = (volatile int *) 0x0


As you can see, I can see exactly where the error happened, and I can even see that it happened because the address of the pointer 'i' was 0 when I tried to store something into it.

3) You know this is going to happen (exception is reproducible) and you have JTAG hardware and free I/O pins for the JTAG interface.

Go set up OpenOCD! Debugging stuff using a live GDB session makes life much easier; you can break at random points in code execution, change between tasks, set breakpoints/watchpoints etc. More info: https://github.com/espressif/esp-idf/bl ... penocd.rst


Anyway, hope that helps.

gistfile2.txt

https://www.matthias-jentsch.de/2017/02/16/on-chip-debugging-on-esp32-with-eclipse-and-openocd/
Connecting the Olimex ARM-USB-OCD-H to the ESP-WROOM-32
I’ve connected the following 7 pins of the 20 pin JTAG adapter to the ESP-WROOM-32 board:

ESP32 3.3V => JTAG Pin 1 – VREF
ESP32 ChipPU => JTAG Pin 3 – TTRST_N
ESP32 GND => JTAG Pin 4 – GND
ESP32 MTDI => JTAG Pin 5 – TTDI
ESP32 MTMS => JTAG Pin 7 – TTMS
ESP32 MTCK => JTAG Pin 9 – TTCK
ESP32 MTDO => JTAG Pin 13 – TTDO



src/openocd -s tcl/ -f tcl/interface/ftdi/olimex-arm-usb-tiny-h.cfg  -f board/esp32-wrover.cfg