debugprobe
debugprobe copied to clipboard
Add a CMSIS compatible implementation for picoprobe
- FIx a bug where SWDIO was left low at the end of a write
- Add a PIO driven implementation of CMSIS-DAP transfer APIs
- Add descriptors and task callbacks for v1 (HID) and v2 (Bulk) CMSIS-DAP protocols
For now, leave the default protocol selection set to the existing openocd interface.
Compiling against gcc version 11.2.1 20220111 I get
[ 52%] Building C object CMakeFiles/picoprobe.dir/home/bon/devel/pico/pico-sdk/src/rp2_common/pico_printf/printf.c.obj /home/bon/devel/pico/pico-sdk/src/rp2_common/pico_printf/printf.c: In function _ftoa': /home/bon/devel/pico/pico-sdk/src/rp2_common/pico_printf/printf.c:354:5: internal compiler error: Illegal instruction 354 | if (value < -DBL_MAX) | ^~ 0x1521b50 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char const*, __va_list_tag () [1], diagnostic_t) ???:0 0x15227d6 internal_error(char const, ...) ???:0 0xb7838f crash_signal(int) ???:0 0x171b289 __gmpn_mul_basecase ???:0
Building with gcc-arm-none-eabi-10.3-2021.10 works.
If GCC is crashing then that seems like a bug with GCC, no?
In any case the bug is triggered from code in the SDK. Might be worth raising the issue on the SDK repo instead.
Edit: an issue already exists here : https://github.com/raspberrypi/pico-sdk/issues/903
Thanks for the pointer. With blackmagic hosted (BMDA), I was able to read from another RP-PICO at about 81 kB/s
Interesting, I've not heard of that one. What SWD settings were in use? Is the throughput strongly a function of SWD clock speed, or does it top out at some point with the clock <25MHz?
Note that I'm still discovering more places where there's unecessary latency, but for now the focus is compatibility with other debug tools rather than raw speed.
https://github.com/blackmagic-debug/blackmagic. The first test used the default 4 M. With higher speed, I get ´´´> ./blackmagic -f 16M -S 100k -r /tmp/bla Black Magic Debug App v1.8.0-211-g018fc517 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, JLink and libftdi/MPSSE Using 2e8a:000c E660C0D1C7305737 Raspberry Pi Picoprobe Read/Verify succeeded for 102400 bytes, 124.878 kiB/s´´´
I would love to see a blackmagic firmware implementation for the Pico.
B.t.w, https://git.lain.faith/sys64738/DragonProbe.git is another CMSIS-DAP for RP Pico with SDW/JTAG Pio implementation.
I would love to see a blackmagic firmware implementation for the Pico.
As of 1.8.0 it appears to do so - https://github.com/blackmagic-debug/blackmagic/releases/tag/v1.8.0
This is with RP Pico as a target, but not as a debugger host running the blackmagic firmware.
I find it nice for all of us to have a natural implementation of PIO + CMSIS-DAP for RasPi Pico like this. But I want merging of it considered thoughtfully. Doesn't it going to spoil the simplicity of picoprobe which is excel at serving a great learning opportunity for someone new to SWD?
The functionality is no different. In fact using CMSIS-DAP v2 makes setup on Windows easier, as you don't have to manually assign the interface driver using Zadig.
I've been able to get this working.
- Build and install the latest version of OpenOCD from git[^1]. If you're from the future, you need OpenOCD v0.12.0.
- Build this branch, or download the attached UF2 file, and flash it onto your Pico.
- Use the following command to flash the program:
openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c 'adapter speed 10000; program {build/MyProgram} verify reset;' - Open a debugger using
arm-none-eabi-gdb build/MyProgram. Runtarget remote :3333to attach to the target device core 0. Runtarget remote :3334to attach to core 1.[^2]
[^1]: this is required because we need an OpenOCD with this patch. [^2]: my understanding is that the dual-debugger situation will be resolved in 0.13.0, when a different change will allow for multiple threads in the same debugger.
I'm testing this, but the speed is still the same as before with the normal picoprobe. I'm getting:
Test with openocd from the raspberrypi repo:
time openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c 'adapter speed 10000; program example_blink_custom.elf verify reset; exit;' Open On-Chip Debugger 0.11.0-g228ede4 (2022-10-22-00:53) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : auto-selecting first available session transport "swd". To override use 'transport select
'. Info : Hardware thread awareness created Info : Hardware thread awareness created Info : RP2040 Flash Bank Command Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E660C0D1C7658C2F Info : CMSIS-DAP: SWD 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 : High speed (adapter speed 10000) may be limited by adapter firmware. Info : clock speed 10000 kHz Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x00000001 Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x10000001 Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints Info : starting gdb server for rp2040.core0 on 3333 Info : Listening on port 3333 for gdb connections target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00 ** Programming Started ** Info : RP2040 B0 Flash Probe: 2097152 bytes @10000000, in 512 sectors target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 Info : Writing 270336 bytes starting at 0x0 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 ** Programming Finished ** ** Verify Started ** target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00 ** Verified OK ** ** Resetting Target **
real 1m12,218s user 0m0,299s sys 0m1,344s
Test with openocd from the openocd-org repo:
time ../../openocd-org/src/openocd -f ../../openocd-org/tcl/interface/cmsis-dap.cfg -f ../../openocd-org/tcl/target/rp2040.cfg -s ../../openocd-org/tcl -c 'adapter speed 10000; program example_blink_custom.elf verify reset; exit;' Open On-Chip Debugger 0.12.0-rc2+dev-00962-g12ce17094 (2022-10-28-23:25) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E660C0D1C7658C2F 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 10000 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 Info : starting gdb server for rp2040.core1 on 3334 Info : Listening on port 3334 for gdb connections [rp2040.core0] halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00 [rp2040.core1] halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00 ** Programming Started ** Info : Found flash device 'win w25q16jv' (ID 0x001540ef) Info : RP2040 B0 Flash Probe: 2097152 bytes @0x10000000, in 32 sectors
Info : Padding image section 1 at 0x100413f8 with 8 bytes (bank write end alignment) Warn : Adding extra erase range, 0x10041400 .. 0x1004ffff ** Programming Finished ** ** Verify Started ** ** Verified OK ** ** Resetting Target **
real 1m8,188s user 0m0,228s sys 0m1,295s
Test with the picoprobe master branch:
time sudo openocd -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s interface/picoprobe.cfg -f target/rp2040.cfg -c 'adapter speed 10000; program example_blink_custom.elf verify reset; exit;' Open On-Chip Debugger 0.11.0-g228ede4 (2022-10-22-00:53) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html CDRTOSConfigure Info : only one transport option; autoselect 'swd' adapter speed: 5000 kHz
Info : Hardware thread awareness created Info : Hardware thread awareness created Info : RP2040 Flash Bank Command Info : clock speed 10000 kHz Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x00000001 Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x10000001 Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints Info : starting gdb server for rp2040.core0 on 50000 Info : Listening on port 50000 for gdb connections target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00 ** Programming Started ** Info : RP2040 B0 Flash Probe: 2097152 bytes @10000000, in 512 sectors
target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 Info : Writing 270336 bytes starting at 0x0 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 ** Programming Finished ** ** Verify Started ** target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 ** Verified OK ** ** Resetting Target **
real 1m14,066s user 0m0,001s sys 0m0,008s
Test with pico_debug repository from the essele:
time sudo gdb-multiarch -ex "target extended-remote /dev/ttyACM0" -ex "load" -ex "quit" example_blink_custom.elf GNU gdb (Ubuntu 12.0.90-0ubuntu1) 12.0.90 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: https://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"... Reading symbols from example_blink_custom.elf... Remote debugging using /dev/ttyACM0 Warnung: multi-threaded target stopped without sending a thread-id, using first non-exited thread 0x000000ea in ?? () Loading section .boot2, size 0x100 lma 0x10000000 Loading section .text, size 0x7580 lma 0x10000100 Loading section .rodata, size 0x27f0 lma 0x10007680 Loading section .big_const, size 0x36fd8 lma 0x10009e70 Loading section .binary_info, size 0x24 lma 0x10040e48 Loading section .data, size 0x58c lma 0x10040e6c Start address 0x100001e8, load size 267256 Transfer rate: 193 KB/sec, 13362 bytes/write. Detaching from program: /home/hbo/Dokumente/projektarbeit/pico_dateien/example_blink_custom/build/example_blink_custom.elf, Remote target Remote doesn't know how to detach
real 0m1,632s user 0m0,001s sys 0m0,005s
In short:
- picoprobe master branch + openocd from raspberrypi: 1m14,066s
- P33M:picodebug branch + openocd from raspberrypi: 1m12,218s
- P33M:picodebug branch + openocd from openocd-org: 1m8,188s
- your implementation pico-debug: 0m1,632s
For me the last one is more practical, because debugging works in Visual Studio Code and it's pretty fast. Before I tried the picoprobe, I've used an STLink/v2 clone with blackmagicprobe, which was also really fast. Anyways, the STLink/v2 has no UART pins available. Therefore I prefer the probe from essele. There is also a discussion on the Raspberry Forum:
https://forums.raspberrypi.com/viewtopic.php?t=337284
I'm using Windows 11 with Linux Mint 21 in VirtualBox with USB forwarding.
You're right @pingufreak. I hadn't paid much attention to the speed, but this is still super slow. Here's a fix to take it from 4KiB/s to theoretically 500KiB/s:
commit be2ef5ada5d357efe4ac6b99727735881d418bbf (HEAD -> picodebug)
Author: Flaviu Tamas <[email protected]>
Date: Fri Oct 28 17:58:53 2022 -0400
Improve debugger performance
DAP_PACKET_COUNT indicates the number of messages that the probe may
have in flight at any time. With this set to 2, the computer is forced
to send just two messages, wait for those messages to be replied to, and
then submit remaining messages. Looks like in practice, a message is a
single word flash read or write.
Since USB places a minimum bound of 2ms delay on each message, that
comes out to an absolute max speed of 3.9KiB/s.
If we instead change this to allow 255 messages simultaniously in
flight, we get a theoretical max of 500KiB/s since our pipeline is much
wider.
Unfortunately, I think this is the best we can do with the RP2040 as the
debugger. USB full-speed supports a max packet size of 64, so while DAP
allows packets up to 1024 bytes, we can't do that because we'd have to
use USB high-speed.
diff --git a/include/DAP_config.h b/include/DAP_config.h
index e05e27b..e84a704 100755
--- a/include/DAP_config.h
+++ b/include/DAP_config.h
@@ -95,7 +95,7 @@ This information includes:
/// This configuration settings is used to optimize the communication performance with the
/// debugger and depends on the USB peripheral. For devices with limited RAM or USB buffer the
/// setting can be reduced (valid range is 1 .. 255).
-#define DAP_PACKET_COUNT 2U ///< Specifies number of packets buffered.
+#define DAP_PACKET_COUNT 255U ///< Specifies number of packets buffered.
/// Indicate that UART Serial Wire Output (SWO) trace is available.
/// This information is returned by the command \ref DAP_Info as part of <b>Capabilities</b>.
$ time openocd -d2 -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c 'adapter speed 10000; program {file} verify reset exit;'
...
openocd -d2 -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c 0.11s user 0.48s system 8% cpu 6.628 total
U2F file download (I also updated my original comment)
While the performance comparisons are useful they are out of scope. This pull request does as the title says it does - change the driver interface to one that's more widely supported.
@P33M Understood--however in this particular case, the performance improvement comes from a 1-line config file change. It might be nice to get it in in the same changeset to avoid a perhaps months-long delay in merging it as another PR.
@P33M : You are right. Just one note at the end, it works for me now. It's pretty fast and I like it!
Will JTAG transport be supported?
Thanks and great work, btw.
You're right @pingufreak. I hadn't paid much attention to the speed, but this is still super slow. Here's a fix to take it from 4KiB/s to theoretically 500KiB/s:
$ time openocd -d2 -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c 'adapter speed 10000; program {file} verify reset exit;' ... openocd -d2 -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c 0.11s user 0.48s system 8% cpu 6.628 totalU2F file download (I also updated my original comment)
This does not do anything for me. Speed is the same... flashing over swd a stm32f1xxx target at about 26kB/sec.
If in a VM, verify you use USB2/3 instead of USB1 ;)
jandy123 @.***> schrieb am Do., 3. Nov. 2022, 15:46:
You're right @pingufreak https://github.com/pingufreak. I hadn't paid much attention to the speed, but this is still super slow. Here's a fix to take it from 4KiB/s to theoretically 500KiB/s:
$ time openocd -d2 -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c 'adapter speed 10000; program {file} verify reset exit;' ... openocd -d2 -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c 0.11s user 0.48s system 8% cpu 6.628 total
U2F file download https://github.com/raspberrypi/picoprobe/files/9892221/picoprobe.zip (I also updated my original comment)
This does not do anything for me. Speed is the same... flashing over swd a stm32f1xxx target at about 26kB/sec.
— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/picoprobe/pull/31#issuecomment-1302224354, or unsubscribe https://github.com/notifications/unsubscribe-auth/APZW37L2Q5O5W5VNHRVLTE3WGPF4PANCNFSM52WXO37A . You are receiving this because you were mentioned.Message ID: @.***>
If in a VM, verify you use USB2/3 instead of USB1 ;)
Sorry, but I'm a bit lost. Is there anything to gain in practice? I mean, the device is USB 1.1...
Will JTAG transport be supported?
See #44
with openocd 0.12.0-rc2 and picoprobe-cmsis-v1.0.1 my timers are no longer running with the following prelaunch commands for cortex-debug in vscode "preLaunchCommands": [ "monitor init", "monitor reset init", "monitor halt", ], this used to work with the customer openocd and older version of picoprobe. am I missing something
issuing a monitor reset on gdb resets pico and they start counting. but not with above setup. If I break anywhere they reset back to zero. and stay like that
Please open a new issue in this repo.