Debugging with OpenOCD and GDB

[f.h-f.s.]

Ever since I started working with the esp32 I haven't been able to debug properly.
I'm using a LoPy and a olimex arm-usb-ocd-h.
I'm building and debugging with VisualGDB.

I already posted about this problem on their forum.
https://sysprogs.com/w/forums/topic/esp ... t-halting/

Alot of nagging about not being able to set breakpoints. Not hitting breakpoints at all. Almost hitting the breakpoint, actually stopping the line before the breakpoint but this is not communicated to the debugger.

I had a conversation about this on IRC, with Sprite_tm and his conclusion was that it was a issue caused by the openocd included in VisualGDB if I'm not mistaken.

So I went ahead and tried debugging on a linux system after having built openocd. It seemed to work better. On I went trying to cross-compile for windows. I couldn't figure out how/didn't have time to fix all the errors in the make stage. Using the msys2 environment it was alot easier building openOCD thank god.

So I had the latest build of openOCD and I started debugging a program I had built with VisualGDB.
(I'm unable to flash the program using VisualGDB using this version of openocd, but I guess thats another issue.)

I am still stuck with the debug controller resetting randomly:

Code: Select all

(gdb) c
Continuing.
esp32.cpu0: Debug controller was reset (pwrstat=0xFF, after clear 0xFF).
esp32.cpu0: Core was reset (pwrstat=0xFF, after clear 0xFF).
esp32.cpu1: Debug controller was reset (pwrstat=0xFF, after clear 0xFF).
esp32.cpu1: Core was reset (pwrstat=0xFF, after clear 0xFF).
esp32.cpu0: Debug controller was reset (pwrstat=0xE5, after clear 0x5F).
esp32.cpu0: Target halted, pc=0x40080A80

Program received signal SIGTRAP, Trace/breakpoint trap.
0x40080a80 in ?? ()

The program halts at the scheduler start, and I continue. The debug controller resets and I press CTRL+C.

Sometimes the breakpoint does hit but the thread is gone:

Code: Select all

(gdb) hb ble.cpp:91
Hardware assisted breakpoint 1 at 0x4014e77e: file ble.cpp, line 91.
(gdb) c
Continuing.
esp32.cpu0: Target halted, pc=0x4014E77E
[Switching to Thread 1073676856]
(gdb)

OpenOCD output:

Code: Select all

Error: FreeRTOS: uxTopUsedPriority is not defined, consult the OpenOCD manual for a work-around

And I'm unable to issue any other gdb commands to the jtag debugger.

VisualGDB is also behind on the newest esp-idf which is also killing me, very, very slowly.

Full gdb output: http://pastebin.com/Gt6HPF0F
Full OpenOCD output: http://pastebin.com/RMQ8XvxB

Any help would be appreciated! all these issues stacking on top of each other isn't speeding up development ='(

[WiFive]

Workaround seems to be implemented: https://github.com/espressif/esp-idf/se ... edPriority

You are not using https://github.com/espressif/openocd-esp32 and following http://esp-idf.readthedocs.io/en/latest/openocd.html ?

[f.h-f.s.]

Ooh cool didn't know you could search like that in github.
I built from https://github.com/espressif/openocd-esp32
Weird, I guess ill check if I updated the repo.

But still the debug controller resetting

[WiFive]

No you're right the version in your screen dump matches the latest commit in that repo. It didn't match the version from the docs which was outdated.

I don't think lopy has any circuitry that would interfere with debug lines right?

[f.h-f.s.]

I don't think the LoPy has any circuit that would interfere. There is a sx1272 radio module on it but that is hooked up to other pins.
There is a led and a button on the same pins as jtag but I'm not using those. No idea whats beneath the cover.

I built the program with "-Wl,--undefined=uxTopUsedPriority" now my openocd is nagging:

Code: Select all

Error: FreeRTOS maximum used priority is unreasonably big, not proceeding: 1395604035

It could be that I'm not using the latest esp-idf version since I'm using VisualGDB.

It still resets the debug controller:

Code: Select all

(gdb) hb ble.cpp:104
Hardware assisted breakpoint 1 at 0x4014e7e8: file ble.cpp, line 104.
(gdb) c
Continuing.
esp32.cpu0: Debug controller was reset (pwrstat=0xFC, after clear 0xFC).
esp32.cpu0: Core was reset (pwrstat=0xFC, after clear 0xFC).
esp32.cpu1: Debug controller was reset (pwrstat=0xFE, after clear 0xFE).
esp32.cpu1: Core was reset (pwrstat=0xFE, after clear 0xFE).
The target is not running when halt was requested, stopping GDB.

or all threads disappear:

Code: Select all

(gdb) hb ble.cpp:104
Hardware assisted breakpoint 1 at 0x4014e7e8: file ble.cpp, line 104.
(gdb) c
Continuing.
esp32.cpu0: Target halted, pc=0x4014E7E8
[Switching to Thread 1073676704]
(gdb) c
Continuing.
Cannot execute this command without a live selected thread.
(gdb) q

When it does halt I can restart openocd and gdb and It's still at that breakpoint:

Code: Select all

Remote debugging using localhost:3333
esp_gap_cb (event=<optimized out>, param=0x3fff00b8) at ble.cpp:104
104                                             ESP_LOGI(TAG, "RSSI: %d", scan_result->scan_rst.rssi);
(gdb)

but continuing resets the debug controller again:

Code: Select all

(gdb) c
Continuing.
esp32.cpu0: Debug controller was reset (pwrstat=0xFC, after clear 0xFC).
esp32.cpu0: Core was reset (pwrstat=0xFC, after clear 0xFC).
esp32.cpu1: Debug controller was reset (pwrstat=0xFE, after clear 0xFE).
esp32.cpu1: Core was reset (pwrstat=0xFE, after clear 0xFE).

GDB log: http://pastebin.com/66QerYrs
OpenOCD log: http://pastebin.com/gKrw9tpH

[BuddyCasino]

I found OpenOCD / GDB debugging to be flaky as well. It takes some fiddling until it actually starts to hit the breakpoints.
I also get lots of these:

Code: Select all

Error: esp32.cpu0: xtensa_read_memory (line 926): DSR (8000CC13) indicates DIR instruction generated an exception!
Warn : esp32.cpu0: Failed reading 1 bytes at address 0x00000000
Error: esp32.cpu0: xtensa_read_memory (line 926): DSR (8000CC13) indicates DIR instruction generated an exception!
Warn : esp32.cpu0: Failed reading 4 bytes at address 0xD20F61B6

[snahmad75]

I am getting these with using Visual DGB with esp32 and olimex arm-usb-ocd-h openocd


Targets connected.
Target halted. PRO_CPU: PC=0x400D73C0 (active) APP_CPU: PC=0x4019E6CA
Target halted. PRO_CPU: PC=0x4019E6CA APP_CPU: PC=0x4009206F (active)
Target halted. PRO_CPU: PC=0x40084384 APP_CPU: PC=0x4009206F (active)