majbthrd

@hathach , that's so strange, as I used Linux to test the RT1010 port. This weekend, I'll take a more in depth look.

@hathach, I think the stack size change that I suggested was unnecessary. I measured peak stack usage at 684 bytes, and that is below the original, default of 1024 bytes....

> Ooops, I will try to do more test, maybe it is some OS setting, btw which Linux distro you are testing with, I am on ubuntu 20.04 I'm testing...

I saw the goal of spedi to be recovery of information about the firmware execution structure without the aid of prior knowledge of the code. At the moment, if the...

I've already implemented a TinyUSB-based CMSIS-DAP that runs on rp2040 core0 and debugs core1. Since most debugging tools don't yet support multi-drop (particularly for CMSIS-DAP), including Raspberry's own OpenOCD fork,...

@liamfraser , I probably need to tweak the README.md language for clarity. I was originally going to link directly to CMSIS_5, but then realized when testing the instructions that TinyUSB...

> Note that the Raspberry Pi OpenOCD fork absolutely supports multi-drop and debugging of both cores @kilograham , I don't believe the fork yet supports multi-drop for CMSIS-DAP (but neither...

> @majbthrd Don't reply on TinyUSB submodules, it is only meant to run examples within tinyusb. I would expect other project just clone tinyusb witthout any of its submodules. Since...

That's an interesting idea! The compiler automatically takes care of de-conflicting memory spaces; core0 would run the debugger and core1 would run the user code. It might be well suited...

One the topic of CMSIS-DAP alternatives for RP2040: If you haven't already seen it, I submitted a PR to support CMSIS-DAP multi-drop with Raspberry Pi's fork of OpenOCD: https://github.com/raspberrypi/openocd/pull/17 I...