search

majbthrd / pico-debug

virtual debug pod for RP2040 "Raspberry Pi Pico" with no added hardware
385 stars 50 forks source link

MacOS: CMSIS-DAP command CMD_DISCONNECT failed #8

Closed frederikvs closed 3 years ago

frederikvs commented 3 years ago

Brilliant project - unfortunately I seem to be running into an issue.

I've downloaded the precompiled pico-debug-gimmecache.uf2 and loaded it onto my raspberry pi pico. I've also compiled the accompanying openocd. I can connect gdb to it, load software, inspect registers, etc. However, when I try to continue in gdb, stuff breaks down, and i get a long sequence of CMSIS-DAP command XXX failed and hid_error is not implemented yet.

gdb output looks like this 

(gdb) tar ext localhost:3333
Remote debugging using localhost:3333
0x2003bd12 in ?? ()
(gdb) load
Loading section .boot2, size 0x100 lma 0x10000000
Loading section .text, size 0x5830 lma 0x10000100
Loading section .rodata, size 0x394 lma 0x10005930
Loading section .binary_info, size 0x24 lma 0x10005cc4
Loading section .data, size 0x2e0 lma 0x10005ce8
Start address 0x100001e8, load size 24520
Transfer rate: 8 KB/sec, 4086 bytes/write.
(gdb) info registers
r0             0x2  2
r1             0x1  1
r2             0x2003c0a9   537116841
r3             0xd0000000   -805306368
r4             0xffffffff   -1
r5             0xffffffff   -1
r6             0xb007c0d3   -1341669165
r7             0x4005801c   1074102300
r8             0xffffffff   -1
r9             0xffffffff   -1
r10            0xffffffff   -1
r11            0xffffffff   -1
r12            0x40008000   1073774592
sp             0x20040000   0x20040000
lr             0x2003bd13   537115923
pc             0x100001e8   0x100001e8 <_entry_point>
xPSR           0x21000000   553648128
msp            0x20041f00   0x20041f00
psp            0xfffffffc   0xfffffffc
primask        0x0  0
basepri        0x0  0
faultmask      0x0  0
control        0x0  0
(gdb) monitor reset init
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
(gdb) continue
Continuing.
error writing data: hid_error is not implemented yet

Program stopped.
0x000000ee in ?? ()

openocd output looks like this (I've put in a few newlines right before doing continue in GDB) : 

Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Warn : target was in unknown state when halt was requested
Info : RP2040 B0 Flash Probe: 2097152 bytes @10000000, in 512 sectors

target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
Info : Writing 24520 bytes starting at 0x0
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1781 ms). Workaround: increase "set remotetimeout" in GDB
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00

Error: error writing data: hid_error is not implemented yet
Warn : target rp2040.core0 is not halted (gdb fileio)
Polling target rp2040.core0 failed, trying to reexamine
Error: error writing data: hid_error is not implemented yet
Error: CMSIS-DAP command CMD_DISCONNECT failed.
Error: error writing data: hid_error is not implemented yet
Error: CMSIS-DAP command CMD_CONNECT failed.
Error: error writing data: hid_error is not implemented yet
Error: CMSIS-DAP command CMD_DISCONNECT failed.
Error: error writing data: hid_error is not implemented yet
Error: CMSIS-DAP command CMD_CONNECT failed.
Error: error writing data: hid_error is not implemented yet
Error: CMSIS-DAP command CMD_SWD_Configure failed.
Error: error writing data: hid_error is not implemented yet
Error: error writing data: hid_error is not implemented yet
Error: CMSIS-DAP command CMD_DISCONNECT failed.
Error: error writing data: hid_error is not implemented yet
Error: CMSIS-DAP command CMD_CONNECT failed.
Error: error writing data: hid_error is not implemented yet
Error: CMSIS-DAP command CMD_SWD_Configure failed.
Error: error writing data: hid_error is not implemented yet
Error: error writing data: hid_error is not implemented yet
Error: CMSIS-DAP command CMD_DISCONNECT failed.
Error: error writing data: hid_error is not implemented yet
Error: CMSIS-DAP command CMD_CONNECT failed.

(The output is way longer than this, but nothing new.)

Any thoughts on what could be causing this, or suggestions on troubleshooting?

P.S. I'm running on MacOS, and I could compile without the fixes suggested in #5 , but I went back and applied them anyway for good measure. It made no difference to this issue.

majbthrd commented 3 years ago

EDIT: misguided ideas in hindsight... skip ahead to next post...

This has echos of #1 where the user was using either the "rp2040_cmsisdap" or "rp2040_single core" pull requests that Raspberry Pi has been sitting on for the past two months and counting. (The behavior that you show looks similar like the latter.)

I formally added the "rp2040_cmsisdap_demo" branch after that to avoid confusion; would you please confirm with a "git branch" in the openocd source code directory that you are using that branch?

I have to plead ignorance... how common is OpenOCD usage in MacOS? I ask because I don't know anyone who uses it with a Mac (or uses a Mac outright). Have you previously been able to use Raspberry Pi's OpenOCD fork (what this is based on)?

Given #5 and what limited information I can find online, it is also not clear to me if MacOS + OpenOCD is just hostile to CMSIS-DAP (the open protocol that pico-debug uses).

There is nothing OpenOCD specific about pico-debug; I use pico-debug frequently with Rowley Crossworks for ARM, for example. pyOCD is open-source and is supposed to be an OpenOCD alternative, but I admit that I haven't had the time to set it up and write instructions. If you were so inclined to try it, that might be an alternative.

majbthrd commented 3 years ago

Hmmm... something really basic that I forgot to ask: what program are you loading?

If you are using something based on pico-sdk (which is a lot of code out there), did you follow the instructions of using the modified pico-sdk?

Would you try something basic like "blinky" in the following:

https://github.com/majbthrd/pico-demos

The reason I ask is because pico-sdk normally rewrites the PLL like it owns the entire chip, and that pulls the rug out from under pico-debug. I submitted a patch to pico-sdk a while back to fix that (since they had not considered something like pico-debug), but you know how that story goes.

frederikvs commented 3 years ago

Ah, I seem to have missed the point that a modified SDK was needed. I was just using my own application, built with the standard pico sdk.

Building blinky from pico-demos does work properly : I can load, run, break, etc... :-)

Minor issue : I've had to modify blinky's makefile to add -std=c++11 to the g++ command for $(BUILD)/elf2uf2$(EXE_SUFFIX): ./elf2uf2/main.cpp. Otherwise my compiler would complain about error: delegating constructors are permitted only in C++11 and the like.

Can I just point my application to your pico-sdk and it should all work? Or do I also need to modify stuff in my cmake config or something?

majbthrd commented 3 years ago

Thanks for the pointer on elf2uf2; I will revise that.

Yes, you can just point to whichever pico-sdk being used; it should just be the environmental variable for the path.

I really wish Raspberry Pi would incorporate my pull request (the source code tweak) into pico-sdk:

move PLL reset code from clocks driver to pll driver https://github.com/raspberrypi/pico-sdk/pull/110

but there are not enough pico-debug users at the moment for them to care. Speaking of that, if you do like pico-debug, please consider giving it a star. It might help getting pico-debug to be taken more seriously.

frederikvs commented 3 years ago

For future reference, in case anybody else sees the same error message :

At some point I accidentally had my stdio running over usb again, and that gave the same kind of error messages.