A good gdb.cmd for Pi Pico

[rteodor]

I am struggling for some weeks to do early debugging on Pi Pico: meaning debug with breakpoints before and just after main.

Two main issues are hunting me:
1) breakpoints don't work from the beginning. They work after the program has started and then hit Ctrl+C. By then its too late.
2) 'load' does not always work. Sometimes it works just fine, other times it seems parts of boot stage 2 gets zeroed for no reason then execution goes into the bushes.

I am constantly hitting one problem, the other or both. If loading finishes fine then breakpoints don't work. If breakpoints are hit in the stage2 flash then magically some zeroes appear in this flash area and further execution crashes.

Anybody has this problems ?
I tried a couple of combinations of stock and source compiled OpenOCD, gdb, debugprobe, picoprobe. And even with BlackMagic Probe its the same every time.
In addition to my code I also tried to debug the blink example. Also the same.

What I think I am missing is proper gdb initialization. Do you happen to have one that works and could share ?

[jnk0le]

check if there is proper reset handling in openocd. ie. "reset_config none separate" instead of srst

[rteodor]

check if there is proper reset handling in openocd. ie. "reset_config none separate" instead of srst

Tried that option (none separate) and a few more but it is still not working.

Code: [Select]

openocd -c 'adapter speed 5000; reset_config none separate' -f interface/cmsis-dap.cfg -f target/rp2040.cfg
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
none separate

Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=...
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 5000 kHz
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001
Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections

Meanwhile I transmutated a sequence that seems to work for now:

Code: [Select]


target extended-remote 127.0.0.1:3333

monitor init
monitor reset halt
load
monitor sleep 500
monitor gdb_sync
si

b main
b * 0x10000040
monitor gdb_sync
si

monitor flash mdw 0x10000000 64
monitor get_reg pc
p/x $pc
i b

monitor sleep 500
monitor gdb_sync
si
continue
d 2

continue
d 1

layout src

Maybe the breakpoints do not work because gdb sets sw breakpoints too early, before code is copied to RAM by stage2?

As for the stage2 flash corruption ... its strange. In wireshark I see that GDB requests 2 flash writes, one for each section (first one for .boot2 at 0x10000000 of 256 bytes, then a second one at 0x10000100 for whatever size is .text). Maybe there is some read-erase-modify-write problem while writing the .text area ?
Anyway I saw that reading .boot2 area prevents corruption.

I'm on too little sleep to figure more, now. Going into low power mode ....