A good gdb.cmd for Pi Pico - Page 1
Forum section: electronics / general

author: rteodor
author_rank: Frequent Contributor
timestamp: September 11, 2024, 09:22:00 pm
content: 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 ?

author: jnk0le
author_rank: Regular Contributor
timestamp: September 12, 2024, 10:26:38 pm
content: check if there is proper reset handling in openocd. ie. "reset_config none separate" instead of srst

author: rteodor
author_rank: Frequent Contributor
timestamp: September 13, 2024, 06:04:37 am
content: Quote from: jnk0le on September 12, 2024, 10:26:38 pmTried that option (none separate) and a few more but it is still not working.Code:openocd -c 'adapter speed 5000; reset_config none separate' -f interface/cmsis-dap.cfg -f target/rp2040.cfgOpen On-Chip Debugger 0.12.0Licensed under GNU GPL v2For bug reports, readhttp://openocd.org/doc/doxygen/bugs.htmlnone separateInfo : Hardware thread awareness createdInfo : Hardware thread awareness createdInfo : Listening on port 6666 for tcl connectionsInfo : Listening on port 4444 for telnet connectionsInfo : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=...Info : CMSIS-DAP: SWD supportedInfo : CMSIS-DAP: Atomic commands supportedInfo : CMSIS-DAP: Test domain timer supportedInfo : CMSIS-DAP: FW Version = 2.0.0Info : CMSIS-DAP: Interface Initialised (SWD)Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0Info : CMSIS-DAP: Interface readyInfo : clock speed 5000 kHzInfo : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001Info : [rp2040.core0] Cortex-M0+ r0p1 processor detectedInfo : [rp2040.core0] target has 4 breakpoints, 2 watchpointsInfo : [rp2040.core1] Cortex-M0+ r0p1 processor detectedInfo : [rp2040.core1] target has 4 breakpoints, 2 watchpointsInfo : starting gdb server for rp2040.core0 on 3333Info : Listening on port 3333 for gdb connectionsMeanwhile I transmutated a sequence that seems to work for now:Code:target extended-remote 127.0.0.1:3333monitor initmonitor reset haltloadmonitor sleep 500monitor gdb_syncsib mainb * 0x10000040monitor gdb_syncsimonitor flash mdw 0x10000000 64monitor get_reg pcp/x $pci bmonitor sleep 500monitor gdb_syncsicontinued 2continued 1layout srcMaybe 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 ....