majbthrd/dappermime

CMSIS-DAP using TinyUSB

dappermime's Issues

JTAG Support

It would be nice to see JTAG support coming. I would find it a very useful alternative to the expensive FT2232HL.
Is there a plan to implement it?

Version information

There is no version number available from the info command:

cmd : 00.04.
cmd res:00.06.04.ff.ff.ff.ff.ff.ff.ff.ff.ff.ff.ff.ff.ff.

Provide new Raspberry Pi Pico version

The provided version for the Raspberry Pi in the releases section didn't work for me. I had to re-compile the most recent main branch and that fixed it for me.

Here is a binary that works (if you trust me 😁)

raspberry_pi_pico-DapperMime.uf2.gz

For a good getting started experience, it would be great to have a ready to flash binary.

PICO_SDK_PATH variable in Makefile is confusing

The following line does not seem to have any effect

DapperMime/Makefile

Line 4 in 2d31d41

PICO_SDK_PATH = ../../pico-sdk

Right now it seems one has to specify PICO_SDK_PATH as an environment variable. It is unfortunate that after doing git clone --recursive on this repo we have the SDK already downloaded but still we need to do some superfluous environment setup.

DapperMime or pico-debug?

I tried pico-debug and that's exactly what I need to integrate in my project using a 2nd stage bootloader. Problem is there's no cmake file in that repo. Is BOARD=raspberry_pi_pico DapperMime == pico-debug?

Any plans to support WinUSB ?

DAPLink supports both HID and WinUSB . DAPLink in WinUSB mode transfers datas in bulk mode, so transfering speed will be more faster than HID mode.

Please add a LICENCE file

Hi

I work for Raspberry Pi and we're interested in supporting CMSIS-DAP for greater interop between RP2040 debug and various third-party debug tools. Our existing adapter offering is Picoprobe (pico as a SWD adapter) which uses a custom protocol with OpenOCD, and isn't very portable.

I've been using your repo internally for a while, and I think it'd be good to base our CMSIS-DAP support efforts on it. Could you add a permissive OSS licence to the repo?

Do not debug RPI PI pico CPU0 with Dappermime running on CPU0

This is more a hint than an issue.

The RP2040 is the only target using SWD multi-drop and Dappermime the only CMSIS debugger supporting multi-drop I have access too. So I wanted to port the multi-drop changes I did to blackmagic debug probe (BMP) to the BMP CMSIS back-end.
Testing with Dappermime pins connected to the on-board SWD pins let me get detection up. But as soon as the debugger tried to attached to CPU 0, Dappermime hanged until poweroff. Trying to fix that, I fixed a lot of other things. After some time I was sure there is a dappermime problem. Until I attached to CPU2 and things worked ;-)

So to make it clear, you can not attach and halt the CPU where the debugger is running on.

Would it be possible to run Dappermime on CPU1 be default? BMP hosted running on the PC has a -t TEST feature to easy see if things are right. To get the memory map, attach is needed. And so a test run without further arguments will hangs the debugger until power-off. For the principle of least surprise it would be fine if the setup could survive this test ;-)

Provide boardname as amufacturer

Appended patch helps to differentiate at least Dappermime on different boards.
dappermime.diff.gz

Pico SDK No Longer Submodule in TinyUSB

DapperMime/CMakeLists.txt

Line 12 in e5e92ee

set(PICO_SDK_PATH ${TOP}/hw/mcu/raspberrypi/pico-sdk)

I realize this project may not be actively maintained, but I just want to point out for others who may also try building from source that TinyUSB no longer includes the Pico SDK as a submodule as of April 2021, breaking the build script for this project.

Only after fiddling with things for a bit did I realize that there are pre-compiled images available for download in the Releases section of the repo. Linking here for reference.

RP2040 / Pico crappy profiler bash one liner

Just as an FYI for you or Google, I used this (DapperMime) code to build a crappy profiler for the RP2040 or Pico, posting it here in case it's useful for anyone else, feel free to include in your repo if you'd like, otherwise feel free to close.

#!/bin/bash
# This should be run from your pico-sdk based application's build directory, already built, flashed onto a device, and running
# also, openOCD should be running in SWD mode, with pico-debug-core0.cfg  or pico-debug-core1.cfg as the configuration (or similar SWD config).
# You should have a ~/.gdbinit containing only 'file relative_path_to.elf' so GDB is reading the correct symbols for the running code.
# The code should run for the entire sample period. If you have multiple *.dis files, it may not detect the correct assembly.

MAX_SAMPLES=100000
TIMESTAMP=$(date +"%Y_%m_%d_%H_%M_%S")
echo "This will take some time"
(for i in {1..100000}; do echo "mrw 0xE000101C"; done) | nc -w1 127.0.0.1 4444 |  grep -av mrw | grep -av '>' | grep -av pen | sort | uniq -c | sort -n  | tr -d "\0" | awk -- '{gsub(/[ \t\r\n]+$/, "", $2); cmd=sprintf("gdb-multiarch -q --e
val-command='\''info symbol 0x%x'\'' --eval-command quit", $2); printf("echo -n '\''%d\t%x\t'\''; %s \n", $1, $2, cmd);}' | /bin/bash | awk '{cmd=sprintf("grep %s *.dis", $2); gsub(/[\n\r]+$/, "", $0); printf("%s\t\t", $0); system(cmd);}'
> crappy_profiler.output.$TIMESTAMP.txt

The 0xE000101C is the DWT_PCSR register that allows you to monitor the PC register address via the debug interface.

Output looks like this:

683     20001178        render_led_frame + 788 in section .data         20001178:       468a            mov     sl, r1
687     20000f7c        render_led_frame + 280 in section .data         20000f7c:       468a            mov     sl, r1
697     20001158        render_led_frame + 756 in section .data         20001158:       468c            mov     ip, r1
711     20001078        render_led_frame + 532 in section .data         20001078:       468a            mov     sl, r1
712     200010f8        render_led_frame + 660 in section .data         200010f8:       468a            mov     sl, r1
796     200010e4        render_led_frame + 640 in section .data         200010e4:       468b            mov     fp, r1
853     20001358        render_led_frame + 1268 in section .data                20001358:       468b            mov     fp, r1
854     200011e4        render_led_frame + 896 in section .data         200011e4:       468b            mov     fp, r1
861     20001164        render_led_frame + 768 in section .data         20001164:       468b            mov     fp, r1

With from left to right, # of calls in sample set, address of instruction, GDB symbol info, and disassembly.