Debugging question (quick)

[victoryred]

I get the following report from gdb but everything seems good, Is it a file permissions issue?

(gdb) target extended-remote localhost:3333 Remote debugging using localhost:3333 warning: multi-threaded target stopped without sending a thread-id, using first non-exited thread sleep_until (t=) at /home/earle/Arduino/hardware/pico/rp2040/pico-sdk/src/common/pico_time/time.c:398 398 /home/earle/Arduino/hardware/pico/rp2040/pico-sdk/src/common/pico_time/time.c: No such file or directory.

As you know, however, from my browser the file exists.

[peterharperuk]

It looks like you're trying to debug a program that was built on someone elses PC.

[victoryred]

Unfortunately color in the terminal doesn't copy over to the issues page and color has meaning. In this case the color was green and I agree with you, I think it's a link to Earle's github repository.

BTW by any chance do you know of any /dev/ttyACM0 contention issues using picoprobe (cmsis-dap) for upload and debugging? I think I'm seeing one. Upload via serial-monitor opens /dev/ttyACM0 and after the upload performs a commanded reset init resulting in a halt. When debug starts, it can't get the /dev/ttyACM0 resource I think because the upload thread still owns the device.

[lurch]

I'm not sure what you're asking, but picoprobe is designed to use SWD for programming and debugging, not UART. /dev/ttyACM0 is the Linux-side driver of the USB-UART connection exposed by picoprobe, see Chapter 4 and Appendix A of https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf and is used to see the output from the printf functions in your code.

If you've got questions about the Arduino environment, I'm afraid the Raspberry Pi GitHub repos aren't the right place to be asking those.

[victoryred]

I thank you for your advice and understand your position. I have read the pdf and complied with the instructions. My model says that there are two serial paths and that SWD is the second serial path (between 2 picos) and that has to go through the USB-UART connection to get there. I know it sounds like an arduino-ide problem but there is a software chain openocd, serial-monitor, cortex-debug and gdb that actually does the work. That suite is board specific. In that chain there IS a contention issue between the serial monitor with the verify/UPLOAD process taking access first and then the debug process getting locked out of the serial resource. I've been redirected here with the explanation that the board vendor may have code for openocd to work with their boards (pico-tools).

I just duplicated the problem in 2 terminals

T1: $ !1984 openocd -s /home/penta/.arduino15/packages/rp2040/hardware/rp2040/3.6.2/lib/ -f picoprobe_cmsis_dap.tcl Open On-Chip Debugger 0.12.0-g4d87f6d (2023-11-27-12:44) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html 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=E661640843626C27 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

T2: openocd -s /home/penta/.arduino15/packages/rp2040/hardware/rp2040/3.6.2/lib/ -f picoprobe_cmsis_dap.tcl Open On-Chip Debugger 0.12.0-g4d87f6d (2023-11-27-12:44) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : Hardware thread awareness created Info : Hardware thread awareness created Error: couldn't bind tcl to socket on port 6666: Address already in use

What did I expect? A shared resource not exclusive access.

I appreciate your help. I hope I've clarified the issue.

[lurch]

I still think you're misunderstanding things - picoprobe offers multiple USB endpoints over just the one USB cable https://github.com/raspberrypi/picoprobe/blob/master/src/usb_descriptors.c#L132 The CMSIS-DAP endpoints bridge to the SWD connection on the picoprobe, and this is what you talk to with openocd. The CDC-ACM endpoint bridges to the UART connection on the picoprobe, and this is what appears as /dev/ttyACM0 on Linux, which you talk to with minicom.

So I would indeed expect that trying to run two copies of openocd at the same time will fail.

[peterharperuk]

Please ask questions in the forum https://forums.raspberrypi.com/viewforum.php?f=145