MacOS: CMSIS-DAP command CMD_DISCONNECT failed about pico-debug HOT 5 CLOSED

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.

from pico-debug.

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.

from pico-debug.

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?

from pico-debug.

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
raspberrypi/pico-sdk#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.

from pico-debug.

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

• make sure you're compiling with the modified pico-sdk (this includes re-running cmake .., else it keeps using the old pico-sdk).
• make sure you're not using the usb for anything else - e.g. for printf output.

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

from pico-debug.