raspberrypi/debugprobe

debugprobe's Issues

Reserve an ADC pin for target voltage measurement

Debug probes often read the target voltage via some ADC pin (e.g. ST-Link). It would be advisable to reserve such a pin for future use, e.g. GP26 for ADC0.

Allow combining with micropython running on core1

I plan to use picoprobe in a CI environment where I'd like to enable another CDC endpoint that talks to a custom application running on the second core of the pico.

Would there be interest in adding such thing? As a start just a micropython REPL would do, this could even run on the same core as picoprobe if that simplifies things

openocd with picoprobe segfaulting on windows

I followed the instructions in the Getting Started with Pico guide, and built OpenOCD for windows, but when I try to start it, it segfaults. I'm not even sure where to start with this. Is the info and warn details what are expected?

$ src/openocd -f interface/picoprobe.cfg -f target/rp2040.cfg -s tcl
Open On-Chip Debugger 0.10.0+dev-g14c0d0d-dirty (2021-01-27-11:20)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
Warn : Transport "swd" was already selected
adapter speed: 5000 kHz

Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : RP2040 Flash Bank Command
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Segmentation fault

VS Code Debug - openocd listening on wrong port

Dev System Linux Mint 21.1
Debugging via picoprobe

I've managed getting gdb and openocd to work together from the command line, and can set break pts, step through the code, etc. 👍
Had to modify
~/pico/openocd/tcl/target/rp2040.cfg
by adding a line at the bottom
adapter speed 5000

The following command now works:
$openocd -s ~/pico/openocd/tcl -f interface/cmsis-dap.cfg -f target/rp2040.cfg

gdb-multiarch and openocd are successfully communicating over localhost:3333

---

However, setting up the debugger in VS Code is not going so well. 👎
When VS Code launches the debugger, gdb-multiarch times out waiting for a connection to openocd. Inspecting the terminal window shows that vs code sends the following command to launch openocd

$/usr/local/bin/openocd -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s ~/pico/openocd/tcl -f ~/.vscode/extensions/marus25.cortex-debug-1.6.10/support/openocd-helpers.tcl -f interface/cmsis-dap.cfg -f target/rp2040.cfg

This command specifies gdb_port 50000. However, I cannot find where this is being set. There is nothing obvious in settings.json & launch.json.
By the way, if I paste the above command into a terminal and modify the line to gdb_port 3333 then openocd and gdb_multiarch are happy to communicate again.

Attached are the vs code json files.

A little help, please...

vscode_json.zip

stdio output disabled if within a conditional

I've recently picked up a couple of pico boards and I'm using picoprobe and openocd from Linux to flash and run with minicom as the output terminal. All works great. However, there is a nasty bug, and I'm not sure if it is in picoprobe or the SDK itself that disables output if the output is conditional within the main program loop.

This pops up when you don't want output generated each iteration of the main loop. Most times, I just want output if some condition has changed. Like if the new temperature is different from the one already displayed, etc. I wrote a short test case that demonstrates the issue:

#include <stdio.h>
#include "pico/stdlib.h"

#define CEILING 20
#define FLOOR   -CEILING

#define USECONDITIONAL 1

static volatile int value = 0;
static volatile bool dir = true;

int main (void) {
  
  stdio_init_all();
  
  while (1) {
    
    bool current_dir = dir;
    
    value = dir ? value + 1 : value - 1;
    
    if (value == CEILING || value == FLOOR) {
      dir = !dir;
    }
    
#ifndef USECONDITIONAL
    printf ("value: % 2d   dir: %s\n", value, dir ? "up" : "down");
#else
    if (dir != current_dir) {
      printf ("value: % 2d   dir: %s\n", value, dir ? "up" : "down");
    }
#endif    
    
    sleep_ms (500);
  }
}

Above, if USECONDITIONAL is not defined, output to the terminal is fine, counts up, reverses direction, counts down, etc.. However, if it IS defined, all out is disabled. That should not occur. Instead, the only output shown should be when value reaches 20 and the direction changes from up to down and at -20 when the opposite happens.

A short CMakeLists.txt using bug-testcase as the filename could be:

# Set minimum required version of CMake
cmake_minimum_required (VERSION 3.12)

#include build functions from Pico SDK
include ($ENV{PICO_SDK_PATH}/external/pico_sdk_import.cmake)

# Set name of project (as PROJECT_NAME) and C/C++ Standards
project (bug-testcase C CXX ASM)
set (CMAKE_C_STANDARD 11)
set (CMAKE_CXX_STANDARD 17)

# Creates a pico-sdk subdirectory in our project for the libraries
pico_sdk_init()

# point out the CMake, where to find the executable source file
add_executable (${PROJECT_NAME} ${PROJECT_NAME}.c)

target_link_libraries (${PROJECT_NAME} pico_stdlib hardware_adc)

# enable uart output, disable usb output
pico_enable_stdio_uart (${PROJECT_NAME} 1)
pico_enable_stdio_usb (${PROJECT_NAME} 0)

# create map/bin/hex file etc.
pico_add_extra_outputs (${PROJECT_NAME})

Like I said, I'm not sure if this is picoprobe itself or the SDK, but this issue makes debugging with conditional output almost impossible. Let me know if this is SDK itself and I'm happy to move the bug there (if you can migrate it, that's fine too if it needs to move).

error: unknown type name 'uint'

Hi,

When compiling picoprobe in a Linux environment (Ubuntu 20.04) the following error appears:

[ 23%] Building C object CMakeFiles/picoprobe.dir/src/get_serial.c.obj
In file included from /home/user/Documents/RBPico/picoprobe/src/get_serial.c:27:
home/dev/pico-sdk/src/rp2_common/pico_unique_id/include/pico/unique_id.h:72:52: error: unknown type name 'uint'; did you mean 'int'?
   72 | void pico_get_unique_board_id_string(char *id_out, uint len);
      |                                                    ^~~~
      |                                                    int
make[2]: *** [CMakeFiles/picoprobe.dir/build.make:128: CMakeFiles/picoprobe.dir/src/get_serial.c.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:1569: CMakeFiles/picoprobe.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

To fix it, I added #include "pico/types.h" to get_serial.c

#include <stdint.h>
#include "pico/types.h"
#include "pico/unique_id.h"
#include "get_serial.h"

Regards,
David

Can Picoprobe debug STM32 in MDK？

Hello, I have a pico development board and I want to debug STM32 in Keil5, is that possible? I tried a lot, but it doesn't like a typical DAPLink. What setting should I change in the firmware?

Support additional boards

Supporting addition boards via the QWIIC/Stemma QT connector like the following would be a great addition. This is not an exhaustive list, I'm sure many more exist.

• SparkFun Pro Micro - RP2040
• Adafruit QT Py RP2040

I see @smittytone has already started on the Adafruit board.

Open OCD with Picoprobe

When I try to connect Picoprobe for debugging (Installed all the softwares in my Mac as per instructions). Also connected as per the schematic given. But the Open OCD is giving the following error.
"Error: The specified debug interface was not found (picoprobe)".
I think the Picoprobe is not detecting by the OpenOCD.
But when I check the USB Device tree, the Picoprobe shows in it there when connecting.

Please help what to do to correct it.

picoprobe uart doesnt work

Hello, i have pico with burned picoprobe.
I short pin 4 and pin 5 (uart rx and tx).
I open serial terminal, send some chars in terminal and recieve nothing :/
Is i do something wrong ?
why picoprobe is not working as usb\serial converter ?

Using the new cmsis-dap picoprobe is extremely slow.

I have tried the new release of pico-probe and was quite dissapointed..

Using VSCode, with Cmake and Cortex-Debug extensions.
From hitting the debug (F5) to the automatic breakpoint at the main function:

The "elf" file is 497264 bytes.

using "picoprobe.cfg" 13 seconds. (picoprobe commit #33ed0e7)
using "cmsis-dap.cfg" 90 seconds. (picoprobe HEAD)

Step through the debug is also much slower.

I guess there is a bus speed configuration missing in the defaults somewhere, but at the moment that time difference makes the cmsis-dap un-usable.

Document Default Pin Assignment in README.md

EDIT: The issue was caused by improper wiring between the Picoprobe and logic analyzer/Pico. Please provide documentation of the default pin assignment in a README.

1. programmed 2 separate Picos with both the prebuilt picoprobe.uf2 and one I compiled myself
2. hooked up a logic analyzer to the SWDIO and SWDCK pins
3. verified the Picoprobe is seen by the OS:

[1329357.426992] usb 4-2: new full-speed USB device number 124 using uhci_hcd
[1329357.615140] usb 4-2: New USB device found, idVendor=2e8a, idProduct=0004, bcdDevice= 1.00
[1329357.615150] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1329357.615154] usb 4-2: Product: Picoprobe
[1329357.615156] usb 4-2: Manufacturer: Raspberry Pi
[1329357.615158] usb 4-2: SerialNumber: E6616407E3663127
[1329357.620283] cdc_acm 4-2:1.0: ttyACM0: USB ACM device
^C

4. ran openocd (full debug output attached)
   openocd-debug.txt

dan@ender:~/pico/openocd$ openocd -f interface/picoprobe.cfg -f target/rp2040.cfg -s tcl
Open On-Chip Debugger 0.11.0-g610f137 (2022-04-08-16:52)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
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 : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 5000 kHz
Info : DAP init failed

5. logic analyzer shows both SWD pins held high the entire time

I'm sure I must be doing something dumb.

Speed

Flashing an elf through gdb takes aproximately 2 minutes, which is too long compared to the Raspberry Pi 4 SWD or Blackmagic Probe flashing. Is there any improvement ongoing? Also to use PIOs for faster flashing? Thx

Release flashable .uf2 files

For people to easily flash their devices with the Picoprobe firmware, this repo should provide precomompiled .uf2 files that people can just drag-and-drop onto a Pico in bootloader mode, either as a file in the repo or as a Github release.

UART stops receiving after timeout

Running with the firmware that was shipped with the Pi Debug Probe (USB bcdDevice 1.01), the UART to USB seems to timeout and stops receiving after about two seconds.

My test setup is an x86 computer running Ubuntu 22.04, the PDP UART connected to an nRF52833 development kit. The DK and the PDP are connected to the same USB hub and that is connected to the computer.

I can then see serial output from the DK on the DK's debug UART, but not on the PDP's UART.

I then send something to the board through the PDP, the red led next to the USB connector lights up together with the green and yellow leds and after that I start to get the serial output from the DK. As long as serial data is sent, the green led keeps flashing and the red led remains on.

If the serial output is quiet for about two seconds, the red led goes off and after that further serial output is no longer sent. The green led also stops blinking.

This issue prevents it from being used as an USB UART.

Build fails with missing unique_id.h

Hi,

My build fails with a missing unique_id.h, any idea?

[ 24%] Building C object CMakeFiles/picoprobe.dir/src/get_serial.c.obj
/code/probe/picoprobe/src/get_serial.c:27:10: fatal error: pico/unique_id.h: No such file or directory
   27 | #include "pico/unique_id.h"
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.

My pico-sdk is 0f3b79.

Access pico's ram through swd pins using another pico

Okay so I'm trying to write some data to a pi pico using another pico. I know i can use a custom bootloader to achieve this but i want to write a program to a fresh pico (that is not running anything) using another pico.
This can be achieved using openocd and a raspberry pi or another Pico as picoprobe but i don't want to have a Linux machine.
Basically i want to program a pi pico from another pico.

Any suggestions how should I proceed?
My goal is to somehow access the slave pico's ram through the swd pins so i can write data directly to it using the master Pico

Can the source code of the Pico probe be modified to achieve this ? If yes can you guide me on how should I start !?

Activity Indicator

Hello,
I think this request relates somewhat to another open issue but I would like ask something here.
Would it be possible for the development team to modify the Picoprobe firmware to blink the LED when the Picoprobe is uploading the firmware to the Pico?

That's it. Just curious, no biggie.
Regards,
Ron

Can't find a picoprobe device on Ubuntu 22.10.

I follow "Appendix A: Using Picoprobe" in the Pico Getting Started Guide to use a Raspberry Pi Pico debug another Raspberry Pi Pico W (with Wi-Fi).

But got this error:

$ openocd -f interface/picoprobe.cfg -f target/rp2040.cfg -s tcl
Open On-Chip Debugger 0.11.0-g228ede4-dirty (2022-12-15-19:28)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
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 : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Error: Failed to open or find the device
Error: Can't find a picoprobe device! Please check device connections and permissions.

$ lsusb 
...
Bus 001 Device 002: ID 2e8a:000c Raspberry Pi Picoprobe CMSIS-DAP
...

$ ls -l /dev/bus/usb/001/002
crw-rw----+ 1 root plugdev 189, 1 12月 15 19:36 /dev/bus/usb/001/002

PicoProbe wont work, comes up as stuff other than interface 0 and 2 using the precompiled uf2 f

Error: Error connecting DP: cannot read IDR

Hello, I am using as debug rp pico and target rp pico w.

Follow the connections as appendix a and the commands

-f interface/cmsis-dap.cfg -c "adapter speed 5000" -f target/rp2040.cfg -s tcl
i charge picoprobe.uf2 from here

any idea?
Thanks!

Add JTAG support

Given that we already swap probe programs in and out of PIO on the fly, it would be easy enough to add JTAG support.

How does PIO assist in this scenario - is the DAP protocol sufficiently high-level that we could accelerate scan-IR and scan-DR ops?

Reinstalling PicoProbe OpenOCD in Windows 10 - bootstrap and configure problems

Hello there,

I have an issue with a fresh install of Msys2 and PicoProbe OpenOCD compilation. Basically, it could not even get past the bootstrap and configure - these complaining about AC_PROG_CC_C99 or the m4_warn.

Here is the error when I do the bootstrap:

$ ./bootstrap
+ aclocal --warnings=all
+ libtoolize --automake --copy
+ autoconf --warnings=all
configure.ac:33: warning: ac_ext=c
configure.ac:33: ac_cpp='$CPP $CPPFLAGS'
configure.ac:33: ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
configure.ac:33: ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
configure.ac:33: ac_compiler_gnu=$ac_cv_c_compiler_gnu
configure.ac:33: if test -n "$ac_tool_prefix"; then
configure.ac:33:   # Extract the first word of "${ac_tool_prefix}gcc", so it can be a program name with args.
configure.ac:33: set dummy ${ac_tool_prefix}gcc; ac_word=$2
configure.ac:33: { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
configure.ac:33: printf %s "checking for $ac_word... " >&6; }
configure.ac:33: if test ${ac_cv_prog_CC+y}
configure.ac:33: then :
configure.ac:33:   printf %s "(cached) " >&6
configure.ac:33: else $as_nop
configure.ac:33:   if test -n "$CC"; then
configure.ac:33:   ac_cv_prog_CC="$CC" # Let the user override the test.
configure.ac:33: else
configure.ac:33: as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
configure.ac:33: for as_dir in $PATH
configure.ac:33: do
configure.ac:33:   IFS=$as_save_IFS
configure.ac:33:   case $as_dir in #(((
configure.ac:33:     '' is m4_require'd but not m4_defun'd
../autoconf-2.71/lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
../autoconf-2.71/lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
../autoconf-2.71/lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from...
../autoconf-2.71/lib/autoconf/programs.m4:41: _AC_CHECK_PROG is expanded from...
../autoconf-2.71/lib/autoconf/programs.m4:101: AC_CHECK_PROG is expanded from...
../autoconf-2.71/lib/autoconf/programs.m4:221: AC_CHECK_TOOL is expanded from...
../autoconf-2.71/lib/autoconf/c.m4:458: AC_PROG_CC is expanded from...
configure.ac:33: the top level
configure.ac:6: error: possibly undefined macro: dnl
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:26: error: possibly undefined macro: AC_PROG_CC
configure.ac:28: error: possibly undefined macro: m4_warn
configure.ac:29: error: possibly undefined macro: AC_PROG_CC_C99
configure.ac:31: error: possibly undefined macro: AC_REQUIRE

config:

username@DESKTOP-XXXXX MSYS /h/picoprobe/openocd
$ ./configure --disable-werror
configure: loading site script /etc/config.site
checking for makeinfo... makeinfo
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of gcc... gcc3
./configure: line 4903: syntax error near unexpected token `[obsolete],'
./configure: line 4903: `m4_warn([obsolete],'

I'm not sure what's the m4_warn thing there - I'm suspecting it has something to do with the updated tools that are not compatible with the OpenOCD.

Here's the list of what I did earlier:

• PicoProbe Git Commit: 8e3c38f78730ce878ff81448bc3f6c1e6bb06e13
• Msys2 version: msys2-x86_64-20230318.exe
• Following the install instructions from: https://www.raspberrypi.com/documentation/microcontrollers/debug-probe.html

Edit: Wrong place to put the issue - should be in Raspberry Pi's OpenOCD.

error: expected initializer before 'noexcept' void operator delete(void *p, std::size_t n) noexcept { std::free(p); }

Hi,

[100%] Linking CXX executable pioasm
[100%] Built target pioasm
[ 20%] No install step for 'PioasmBuild'
[ 21%] Completed 'PioasmBuild'
[ 21%] Built target PioasmBuild
Scanning dependencies of target picoprobe_probe_pio_h
[ 22%] Generating probe.pio.h
[ 22%] Built target picoprobe_probe_pio_h
Scanning dependencies of target picoprobe
[ 23%] Building C object CMakeFiles/picoprobe.dir/src/led.c.obj
[ 24%] Building C object CMakeFiles/picoprobe.dir/src/main.c.obj
[ 25%] Building C object CMakeFiles/picoprobe.dir/src/usb_descriptors.c.obj
[ 26%] Building C object CMakeFiles/picoprobe.dir/src/probe.c.obj
[ 27%] Building C object CMakeFiles/picoprobe.dir/src/cdc_uart.c.obj
[ 29%] Building C object CMakeFiles/picoprobe.dir/src/get_serial.c.obj
[ 30%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_stdlib/stdlib.c.obj
[ 31%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/hardware_gpio/gpio.c.obj
[ 32%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/hardware_claim/claim.c.obj
[ 33%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_platform/platform.c.obj
[ 34%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/hardware_sync/sync.c.obj
[ 35%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/hardware_uart/uart.c.obj
[ 36%] Building ASM object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/hardware_divider/divider.S.obj
[ 37%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/common/pico_time/time.c.obj
[ 38%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/common/pico_time/timeout_helper.c.obj
[ 39%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/hardware_timer/timer.c.obj
[ 40%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/common/pico_sync/sem.c.obj
[ 41%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/common/pico_sync/lock_core.c.obj
[ 43%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/common/pico_sync/mutex.c.obj
[ 44%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/common/pico_sync/critical_section.c.obj
[ 45%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/common/pico_util/datetime.c.obj
[ 46%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/common/pico_util/pheap.c.obj
[ 47%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/common/pico_util/queue.c.obj
[ 48%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_runtime/runtime.c.obj
[ 49%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/hardware_clocks/clocks.c.obj
[ 50%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/hardware_watchdog/watchdog.c.obj
[ 51%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/hardware_xosc/xosc.c.obj
[ 52%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/hardware_pll/pll.c.obj
[ 53%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/hardware_vreg/vreg.c.obj
[ 54%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/hardware_irq/irq.c.obj
[ 55%] Building ASM object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/hardware_irq/irq_handler_chain.S.obj
[ 56%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_printf/printf.c.obj
[ 58%] Building ASM object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_bit_ops/bit_ops_aeabi.S.obj
[ 59%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_bootrom/bootrom.c.obj
[ 60%] Building ASM object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_divider/divider.S.obj
[ 61%] Building ASM object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_double/double_aeabi.S.obj
[ 62%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_double/double_init_rom.c.obj
[ 63%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_double/double_math.c.obj
[ 64%] Building ASM object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_double/double_v1_rom_shim.S.obj
[ 65%] Building ASM object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_int64_ops/pico_int64_ops_aeabi.S.obj
[ 66%] Building ASM object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_float/float_aeabi.S.obj
[ 68%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_float/float_math.c.obj
[ 68%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_float/float_init_rom.c.obj
[ 69%] Building ASM object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_float/float_v1_rom_shim.S.obj
[ 70%] Building C object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_malloc/pico_malloc.c.obj
[ 72%] Building ASM object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_mem_ops/mem_ops_aeabi.S.obj
[ 73%] Building ASM object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_standard_link/crt0.S.obj
[ 74%] Building CXX object CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_standard_link/new_delete.cpp.obj
/home/pi/pico/pico-sdk/src/rp2_common/pico_standard_link/new_delete.cpp:20:46: error: expected initializer before 'noexcept'
void operator delete(void *p, std::size_t n) noexcept { std::free(p); }
^
/home/pi/pico/pico-sdk/src/rp2_common/pico_standard_link/new_delete.cpp:24:33: error: expected initializer before 'noexcept'
void operator delete[](void *p) noexcept { std::free(p); }
^
CMakeFiles/picoprobe.dir/build.make:585: recipe for target 'CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_standard_link/new_delete.cpp.obj' failed
make[2]: *** [CMakeFiles/picoprobe.dir/home/pi/pico/pico-sdk/src/rp2_common/pico_standard_link/new_delete.cpp.obj] Error 1
make[2]: *** Waiting for unfinished jobs....
CMakeFiles/Makefile2:74: recipe for target 'CMakeFiles/picoprobe.dir/all' failed
make[1]: *** [CMakeFiles/picoprobe.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
pi@raspberrypi:~ $

Take advantage of CMSIS-DAP ecosystem

Hi there! 👋🏽 The Pico is quite exciting!

Fyi, there is an open-source ecosystem of debug adapters for Cortex-M devices, based around the CMSIS-DAP protocol. This protocol is well supported by debuggers, including open source tools like pyocd and openocd. And it's very fast in the v2 bulk-pipe form.

Aside from the protocol and reference code, we have the widely used open source DAPLink project that provides debug probe firmware with lots of extra features. Notably, DAPLink is used by micro:bit. We are in the process of switching it to build with gcc by default (ARMmbed/DAPLink#750), as well as support custom SWD implementations—perfect for making use of the Pico's PIO.

We‡ believe working together to enable Pico debug would much more beneficial for the wider community than reimplementing the wheel. We'd be happy to help you take advantage of the existing open source infrastructure for debug, and make available our experience with debug and embedded. Let's talk!

(Btw, I have plans to support the Pico extensively in pyocd. As soon as I get my board(s) on Monday. 😁 It would be nice to work with you on pyocd support.)

‡ I'm speaking for a few of us in Arm Research that work on open source projects like these in our spare time, and sometimes for work.

Configuring UART pins does not change hardware interface used

I had to dip into cdc_uart.c and change uart1 to uart0 since I wanted to use pins 0 and 1 on the board I was using as a debugger.

There should probably be a define for this in picoprobe_config.h

Also- can we get some kind of indicator LED support or hook to customise one? The board I'm using has an RGB LED onboard and I'm basically toggling a LED element in probe_handle_read and probe_handle_write which gives me some "I'm alive" indication, though it's a little rough around the edges.

P.S. this is awesome!

Discussion: SWCLK speed

It has already been mentioned, that clock speed SWCLK does not correspond to the setting done via openocd ("adapter speed"): #47

The wrong calculation happens in sw_db_pio.c:

#define MAKE_KHZ(x) (CPU_CLOCK / (2000 * ((x) + 1)))

Parameter "x" is DAP_Data.clock_delay and calculated in DAP.c which takes DELAY_SLOW_CYCLES and IO_PORT_WRITE_CYCLES into account.

I'm wondering if those parameters are actually of interest and for the picoprobe the setup of the SWCLK is more relevant.

In this case the calculation in MAKE_KHZ() could revert the DAP.c one. Definition would then look like

#define MAKE_KHZ(x) ((CPU_CLOCK / 2000) / (delay * DELAY_SLOW_CYCLES + IO_PORT_WRITE_CYCLES))

Any opinions about this? If not, I would create a PR for this.

Running code on second core hangs processor

I'm not sure if this is related to #45

I've just changed over from the custom Picoprobe implementation to the latest CMSIS-DAP implementation. The dev environment has been working fine for the last couple of months with the custom implementation. This is my first time using openOCD, so I don't have a lot of knowledge about it!

The issue is when I run multicore_launch_core1(_second_core_code); it hangs the pico, it seems to get stuck in the function below in multicore.c

static inline bool multicore_fifo_rvalid(void) {
    return !!(sio_hw->fifo_st & SIO_FIFO_ST_VLD_BITS);
}

my launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Pico Debug",
            "cwd": "${workspaceRoot}",
            "executable": "${command:cmake.launchTargetPath}",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "openocd",
            // This may need to be arm-none-eabi-gdb depending on your system
            "gdbPath": "arm-none-eabi-gdb",
            "device": "RP2040",
            "configFiles": [
                "interface/cmsis-dap.cfg",
                "target/rp2040.cfg"
            ],
            "svdFile": "${env:PICO_SDK_PATH}/src/rp2040/hardware_regs/rp2040.svd",
            "runToEntryPoint": "main",
            "postRestartCommands": [
                "break main",
                "continue"
            ],
            "searchDir": [
                "C:/VSARM/sdk/pico/openocd/scripts"
            ],
            "openOCDLaunchCommands": [
                "adapter speed 10000",
                "tcl_port disabled",
                "telnet_port disabled"
            ],
        }
    ]
}

and terminal output

[2023-01-04T05:27:03.464Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected. You can switch to "DEBUG CONSOLE" to see GDB interactions.
"C:/VSARM/sdk/pico/openocd/openocd.exe" -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s "C:/VSARM/sdk/pico/openocd/scripts" -f "c:/Users/User/.vscode/extensions/marus25.cortex-debug-1.6.9/support/openocd-helpers.tcl" -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 10000" -c "tcl_port disabled" -c "telnet_port disabled"
Open On-Chip Debugger 0.12.0-rc2+dev-g9d92577 (2022-11-16-19:29)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
CDRTOSConfigure
adapter speed: 10000 kHz

Info : tcl server disabled
Info : telnet server disabled
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E661A4D4173B9E23
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 50000
Info : Listening on port 50000 for gdb connections
Info : starting gdb server for rp2040.core1 on 50001
Info : Listening on port 50001 for gdb connections
Info : accepting 'gdb' connection on tcp/50000
[rp2040.core0] halted due to debug-request, current mode: Thread 
xPSR: 0x81000000 pc: 0x100066fe msp: 0x20041fe8
Info : Found flash device 'win w25q16jv' (ID 0x001540ef)
Info : RP2040 B0 Flash Probe: 2097152 bytes @0x10000000, in 32 sectors

Info : New GDB Connection: 1, Target rp2040.core0, state: halted
[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
[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
Info : Padding image section 0 at 0x1000ded0 with 48 bytes (bank write end alignment)
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1617 ms). Workaround: increase "set remotetimeout" in GDB
[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
[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

No license is no license

Thanks for making the code available, but no License (or a readme with a license description) is provided in root and while many source files do have an embedded MIT (and in one case a BSD-3-Clause) license statement, others are completely unlicensed.

As I am sure you know, no license == no license, so hindering the redistribution and modification of the code, if one wants to follow the rules.

Missing licenses:

• src/cdc_uart.c
• src/cdc_uart.h
• src/picoprobe_config.h
• src/probe.h
• src/probe.pio

Picoprobe won't run on Adafruit Feather RP2040

I needed a second RP2040 board to use as a Picoprobe for SWD debugging another Raspberry Pi Pico so I went to Micro Center and purchased an Adafruit Feather RP2040 because they were out of Pi Picos. The board I got appears to be otherwise functional but will not connect to any computer over USB (tested on one Raspberry Pi 4 and two Windows PCs) when running the Picoprobe firmware. Nothing is displayed in lsusb on Linux or device manager on Windows when it is connected. I don't believe there is an issue with my build/install process because I can flash Picoprobe on my other Pi Pico and use it to debug code running on the Feather RP2040. My Pi Pico shows up correctly in lsusb and device manager on all of my computers when running Picoprobe.

Opening serial port on picoprobe breaks target pico USB

Hi
I started using picoprobe as my main programmer/debugger.
However I've encountered a bug, where if I open serial port on picoprobe, target shows as unknown device (cannot get device descriptor).
UART and SWD don't even need to be connected physically and happens only when COM port is open.
This does not occur when using external UART bridge.

Is this a fixable issue? I've been looking for a fix, but now the only solution is using an external converter.
Not a dealbreaker but contrary to Arduino, now I have to use 3 USB ports :(

Don't use Zadig for Windows driver installs

Zadig is a slow, prone to error and fairly overcomplicated to install a driver for Picoprobe on Windows. You should use LibusK-inf-wizard instead and vendor a driver into a Windows installer package.

Attached example targets the Picoprobe VID/PID (Interface 2) and installs in one click (clicking Finish and, uh, extracting the installer notwithstanding).

Windows users might be familiar with this screen from the driver installs of other micro manufacturers:

Yes you have to re-vender if the libUSB version you want to target changes... but if that's a breaking change (do these happen with libUSB windows drivers? I don't know) then right now the first you'll hear of it is bug reports.

Picoprobe_libUSB.zip

LIBUSB_ERROR_TIMEOUT when programming elf

$ ./src/openocd.exe -f tcl/interface/picoprobe.cfg -f tcl/target/rp2040.cfg -s tcl -c "targets rp2040.core0; program ../pico-examples/cmake-build-debug/blink/blink.elf"
Open On-Chip Debugger 0.10.0+dev-g14c0d0d-dirty (2021-02-03-14:28)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
Warn : Transport "swd" was already selected
adapter speed: 5000 kHz

Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : RP2040 Flash Bank Command
Info : clock speed 5000 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: 0x000000ee msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ee 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: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
Info : Writing 24576 bytes starting at 0x0
Error: libusb_bulk_write error: LIBUSB_ERROR_PIPE
Error: libusb_bulk_write error: LIBUSB_ERROR_TIMEOUT
Error: libusb_bulk_read error: LIBUSB_ERROR_TIMEOUT
Error: libusb_bulk_write error: LIBUSB_ERROR_TIMEOUT

building picoprobe failed

While building the picoprobe it fails. I don't know why but it seem that it have something issue with FreeRTOS.

pico w isn't supported?

Hi,

I tried to compile picoprobe for the pico w. Anyways, the pins for LED and SWD have changed on the pico w. Is there already a common solution for this? Else I would change the picoprobe source to be compatible with the pico w.

C:\pico\picoprobe\src\picoprobe_config.h:68:2: error: #error PICO_DEFAULT_LED_PIN is not defined, run PICOPROBE_LED=<led_pin> cmake
   68 | #error PICO_DEFAULT_LED_PIN is not defined, run PICOPROBE_LED=<led_pin> cmake
      |  ^~~~~
C:\pico\picoprobe\src\led.c: In function 'led_init':
C:\pico\picoprobe\src\led.c:39:15: error: 'PICOPROBE_LED' undeclared (first use in this function); did you mean 'PICOPROBE_H_'?
   39 |     gpio_init(PICOPROBE_LED);
      |               ^~~~~~~~~~~~~
      |               PICOPROBE_H_
C:\pico\picoprobe\src\led.c:39:15: note: each undeclared identifier is reported only once for each function it appears in
C:\pico\picoprobe\src\led.c: In function 'led_task':
C:\pico\picoprobe\src\led.c:49:18: error: 'PICOPROBE_LED' undeclared (first use in this function); did you mean 'PICOPROBE_H_'?
   49 |         gpio_put(PICOPROBE_LED, !((led_count >> LED_COUNT_SHIFT) & 1));
      |                  ^~~~~~~~~~~~~
      |                  PICOPROBE_H_
C:\pico\picoprobe\src\led.c: In function 'led_signal_activity':
C:\pico\picoprobe\src\led.c:55:18: error: 'PICOPROBE_LED' undeclared (first use in this function); did you mean 'PICOPROBE_H_'?
   55 |         gpio_put(PICOPROBE_LED, 0);
      |                  ^~~~~~~~~~~~~
      |                  PICOPROBE_H_
NMAKE : fatal error U1077: "C:\PROGRA~2\ARMGNU~1\1142DA~1.3RE\bin\AR19DD~1.EXE": Rückgabe-Code "0x1"
Stop.
NMAKE : fatal error U1077: ""C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.33.31629\bin\HostX86\x86\nmake.exe"": Rückgabe-Code "0x2"
Stop.
NMAKE : fatal error U1077: ""C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.33.31629\bin\HostX86\x86\nmake.exe"": Rückgabe-Code "0x2"
Stop.

Thx

Kind regards,

Pingu

Unable to checkout 'a65b7c9a3e6502127fdb80eb288d8cbdf251a6f4' in submodule path 'CMSIS_5'

Looks like there is some issue checking out the current commit for CMSIS_5 when executing the following line from the "Build and flash picoprobe" section of the User Guide:

When I run git submodule update --init it ends up on branch master with a dirty working directory. If I enter the CMSIS_5 directory, and git reset --hard and remove any untracked files git clean -xfd, I end up on the develop branch. If I try to checkout a65b7c9a3e6502127fdb80eb288d8cbdf251a6f4 with git checkout a65b7c9a3e6502127fdb80eb288d8cbdf251a6f4 I get the following error:

git-lfs filter-process: 1: git-lfs: not found
fatal: the remote end hung up unexpectedly

After installing git-lfs as per the README and repeating the

git reset --hard
git clean -xfd
git checkout a65b7c9a3e6502127fdb80eb288d8cbdf251a6f4

I am in a detached head at a65b7c9a3e6502127fdb80eb288d8cbdf251a6f4. Proceeding to build picoprobe from this point seems to work as expected.

I'm guessing this is outside the control of this repo but I didn't see this documented anywhere, so hopefully this helps others who don't have git-lfs by default like I did.

DTR signal needs to be activated from terminal program

Problem:

tud_cdc_connected is using DTR bit which is used in cdc_uart.c If DTR is not set by host (PC terminal or other device), we can't send anything to host.

same issue with #906, #921, #932

I don't think its necessary to check DTR as discussed in here -> hathach/tinyusb

Until user open the serial port, data buffer will be overridden.

src/class/cdc/cdc_device.h

static inline bool tud_cdc_connected (void)
{
  return tud_cdc_n_connected(0);
}

src/class/cdc/cdc_device.h

bool tud_cdc_n_connected(uint8_t itf)
{
  // DTR (bit 0) active  is considered as connected
  return tud_ready() && tu_bit_test(_cdcd_itf[itf].line_state, 0);
}

how to fix

change tud_cdc_connected() with tud_ready()

PICOPROBE_DEBUG_PROTOCOL is not set properly if PICOPROBE_LED is defined

I was trying to install picoprobe on waveshare rp2040-zero and it was always showing up as "Picoprobe CMSIS-DAP v1" instead of v2.
After hours of head scratching I found that the problem is related to the fact that this board's definition does not have PICO_DEFAULT_LED_PIN declared so I head to add "target_compile_definitions(picoprobe PRIVATE PICOPROBE_LED=25)" to the CMakeLists.txt.
This revealed a bug in picoprobe_config.h, where "#define PICOPROBE_DEBUG_PROTOCOL PROTO_DAP_V2" is under "#ifndef PICOPROBE_LED". Essentially if PICOPROBE_LED is defined, PICOPROBE_DEBUG_PROTOCOL remains undefined and picoprobe falls back to the default v1 protocol.

As a side note, I noticed that the size of the officially released picoprobe.uf2 is ~190k while no matter what I do, my built binary is ~80k or so (slightly bigger for Debug, but still much smaller than the officially released binary). Not really important at this point, but initially I was suspecting that some functionality does not get included into my binary.

If it matters, I am building with VSCode on Windows.

Q: can this expose a gdbstub to usbserial on another device?

Looking at the code I can see you are wiggling the SWD pins but it's not entirely clear what connects over the tiny usb side? What I'm looking to do is use one pico to provide a gdbstub while debugging another pico over the SWD without having to go through the fiddle of setting up a Raspberry Pi with OpenOCD.

Any chance of a quick README for the repo to explain the topology of a picoprobe setup?

Build fails on macOs Monterey

I did:

./bootstrap
./configure --enable-picoprobe --disable-werror

The error I get:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I./src -I./src -I./src/helper -DPKGDATADIR=\"/usr/local/share/openocd\" -DBINDIR=\"/usr/local/bin\" -I./jimtcl -I./jimtcl -isystem /opt/homebrew/Cellar/libusb/1.0.26/include/libusb-1.0 -I/opt/homebrew/Cellar/libusb-compat/0.1.5_1/include -I/opt/homebrew/Cellar/libusb/1.0.26/include/libusb-1.0 -I/opt/homebrew/Cellar/libftdi/1.5_2/include/libftdi1 -I/opt/homebrew/Cellar/libusb/1.0.26/include/libusb-1.0 -I/opt/homebrew/Cellar/hidapi/0.12.0/include/hidapi -I./src/jtag/drivers/libjaylink/libjaylink -I./src/jtag/drivers/libjaylink -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Wpointer-arith -g -O2 -MT src/jtag/drivers/libocdjtagdrivers_la-driver.lo -MD -MP -MF src/jtag/drivers/.deps/libocdjtagdrivers_la-driver.Tpo -c src/jtag/drivers/driver.c -o src/jtag/drivers/libocdjtagdrivers_la-driver.o
In file included from src/jtag/drivers/driver.c:33:
In file included from ./src/jtag/jtag.h:25:
In file included from ./src/helper/binarybuffer.h:25:
In file included from ./src/helper/list.h:5:
./src/helper/types.h:52:13: error: cannot combine with previous 'int' declaration specifier
typedef int _Bool;
            ^
./src/helper/types.h:52:1: warning: typedef requires a name [-Wmissing-declarations]
typedef int _Bool;
^~~~~~~~~~~~~~~~~
In file included from src/jtag/drivers/driver.c:34:
In file included from ./src/jtag/interface.h:30:
In file included from ./src/target/armv7m_trace.h:21:
./src/server/server.h:49:21: error: field has incomplete type 'struct sockaddr_in'
        struct sockaddr_in sin;
                           ^
./src/server/server.h:49:9: note: forward declaration of 'struct sockaddr_in'
        struct sockaddr_in sin;
               ^
./src/server/server.h:67:21: error: field has incomplete type 'struct sockaddr_in'
        struct sockaddr_in sin;
                           ^
./src/server/server.h:49:9: note: forward declaration of 'struct sockaddr_in'
        struct sockaddr_in sin;
               ^
1 warning and 3 errors generated.
make[2]: *** [src/jtag/drivers/libocdjtagdrivers_la-driver.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Any ideas?

libusb errors seen on both RPiOS and macOS

Note This should probably be filed under raspberrypi/openocd.

With a fresh builds of openocd and picoprobe (using Pico Getting Started Guide instructions) on a Pi 400, I'm seeing:

sudo openocd -f interface/picoprobe.cfg -f target/rp2040.cfg -s tcl                                    [ pico ]
Open On-Chip Debugger 0.11.0-g228ede4-dirty (2022-08-10-09:29)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
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 : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 5000 kHz
Error: libusb_bulk_read error: LIBUSB_ERROR_TIMEOUT
Error: libusb_bulk_read error: LIBUSB_ERROR_OVERFLOW
Info : DAP init failed

Error: libusb_bulk_read error: LIBUSB_ERROR_OVERFLOW
openocd: src/jtag/drivers/picoprobe.c:101: picoprobe_bulk_write: Assertion `pkt_hdr->total_packet_length <= PICOPROBE_MAX_PACKET_LENGTH' failed.

I did this on a Pi because I was seeing exactly the same issue under macOS (12.5 on an M1 Mac Mini) and wanted to see if I could get it working a more 'official' way.

Picoprobe is running on a Pico, as is the target.

Let me know if there's more info you need.

OpenOCD isn't pipelining DAP commands to Picoprobe

Even with DAP_PACKET_COUNT=3, I don't see any consecutive OUT transfers. All commands are request/response in step, with large delays between. I see multiple transactions being queued in sequence, and reads being reaped from the FIFO, but the bus analyser says otherwise.

Debug: 623 1726 cmsis_dap.c:1095 cmsis_dap_swd_switch_seq(): SWD line reset
Debug: 624 1741 cmsis_dap.c:768 cmsis_dap_swd_write_from_queue(): Executing 0 queued transactions from FIFO index 0
Debug: 625 1741 cmsis_dap.c:576 cmsis_dap_metacmd_targetsel(): DP write reg TARGETSEL 11002927
Debug: 626 1741 cmsis_dap.c:768 cmsis_dap_swd_write_from_queue(): Executing 4 queued transactions from FIFO index 0
Debug: 627 1741 cmsis_dap.c:791 cmsis_dap_swd_write_from_queue(): DP read reg 0 0
Debug: 628 1741 cmsis_dap.c:791 cmsis_dap_swd_write_from_queue(): DP write reg 0 10
Debug: 629 1741 cmsis_dap.c:791 cmsis_dap_swd_write_from_queue(): DP write reg 8 3
Debug: 630 1757 cmsis_dap.c:791 cmsis_dap_swd_write_from_queue(): DP read reg 4 0
Debug: 631 1757 cmsis_dap.c:884 cmsis_dap_swd_read_process(): Received results of 4 queued transactions FIFO index 0
Debug: 632 1757 cmsis_dap.c:894 cmsis_dap_swd_read_process(): Read result: bc12477
Debug: 633 1757 cmsis_dap.c:894 cmsis_dap_swd_read_process(): Read result: 10000001
Debug: 634 1757 adi_v5_swd.c:239 swd_multidrop_select_inner(): Selected DP_TARGETSEL 0x11002927
Debug: 635 1757 cmsis_dap.c:768 cmsis_dap_swd_write_from_queue(): Executing 3 queued transactions from FIFO index 0
Debug: 636 1773 cmsis_dap.c:791 cmsis_dap_swd_write_from_queue(): DP write reg 8 13
Debug: 637 1773 cmsis_dap.c:791 cmsis_dap_swd_write_from_queue(): AP read reg 0 0
Debug: 638 1773 cmsis_dap.c:791 cmsis_dap_swd_write_from_queue(): DP read reg c 0
Debug: 639 1773 cmsis_dap.c:884 cmsis_dap_swd_read_process(): Received results of 3 queued transactions FIFO index 0
Debug: 640 1773 cmsis_dap.c:894 cmsis_dap_swd_read_process(): Read result: 30003
Debug: 641 1773 cmsis_dap.c:894 cmsis_dap_swd_read_process(): Read result: 0

Traffic highlighted on the trace here is a flash write process.

cc @tom-van

openocd: Failed to claim picoprobe interface

I am not able to use openocd with picoprobe on xubuntu:

~/pico/openocd (rp2040)$ ./src/openocd -f interface/picoprobe.cfg -f target/rp2040.cfg -s tcl
Open On-Chip Debugger 0.11.0-g228ede4 (2022-11-18-18:34)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
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 : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Error: Failed to claim picoprobe interface
Error: Can't find a picoprobe device! Please check device connections and permissions.

The device is detected:

[  848.934684] usb 2-2: USB disconnect, device number 8
[  921.175453] usb 2-2: new full-speed USB device number 9 using ohci-pci
[  921.694255] usb 2-2: New USB device found, idVendor=2e8a, idProduct=0004, bcdDevice= 1.01
[  921.694261] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  921.694263] usb 2-2: Product: Picoprobe CMSIS-DAP
[  921.694265] usb 2-2: Manufacturer: Raspberry Pi
[  921.694266] usb 2-2: SerialNumber: E66160F4235DC136
[  921.710251] cdc_acm 2-2:1.1: ttyACM0: USB ACM device

And I have the 60-openocd.rules in /etc/udev/rules.d from openocd/contrib:

...
# Raspberry Pi Picoprobe
ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="0004", MODE="660", GROUP="plugdev", TAG+="uaccess"
...

Do I miss something? I followed the description refered in the readme file.

Can not getting UART fucntion work as expected on PICO

I am trying to use my Raspberry Pi PICO as a debugger with this project, however the UART function is only works in one direction in my case.

If i set the UART config in picoprobe_confg.h like this which utilizing UART1:

// UART config
#define PICOPROBE_UART_TX 4
#define PICOPROBE_UART_RX 5
#define PICOPROBE_UART_INTERFACE uart1
#define PICOPROBE_UART_BAUDRATE 115200

Only the TX pin is working which could send message to the second usb to uart device.

---

If i set the UART config in picoprobe_confg.h like this utilizing UART0:

// UART config
#define PICOPROBE_UART_TX 0
#define PICOPROBE_UART_RX 1
#define PICOPROBE_UART_INTERFACE uart0
#define PICOPROBE_UART_BAUDRATE 115200

Only the RX pin is working which could receive message from the second usb to uart device.

---

Then I put the UART0 configured firmware into the XIAO RP2040 and it act the same as Raspberry Pi PICO which only the RX pin works.

Please help me on this. I am waiting on the new Picoprobe and that's how I got into this.

Thanks.

Add output indicating direction of SWDIO

To be able to use picoprobe with digital isolators, information about SWDIO direction needs to be also available on isolated side (for tri-stating output).
I don't think this would bee too much effort to add and picoprobe would be more versatile.

Picoprobe-cmsis-dap doesn't appear in `/dev` on macos

On version 1.0, if I check /dev before and then after my probe is connected:

❯ ls /dev > a
❯ ls /dev > b
❯ diff a b
16a17
> cu.usbmodem2102
214a216
> tty.usbmodem2102

However, on version 1.0.1, I see no output from the diff. Additionally, the CMSIS-DAP debugger I'm using (probe-rs) detects the v1.0 firmware but not the v1.0.1 firmware.

In both cases, I am testing this with just the rp2040, with no "chip being tested" connected.

configure: error: no acceptable C compiler found in $PATH

I'm trying to build OpenOCD as described in the Getting Started With Raspberry Pi Pico > Appendix A: Using Picoprobe > Build OpenOCD > Windows.

However, when running the command ./configure --enable-picoprobe --disable-werror , I get an error:
configure: error: no acceptable C compiler found in $PATH

Full output of the command:

$ ./configure --enable-picoprobe --disable-werror
configure: loading site script /etc/config.site
checking for makeinfo... makeinfo
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... no
checking for cc... no
checking for cl.exe... no
checking for clang... no
configure: error: in `/home/AndersBergman/openocd':
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details

See config.log for the details.

My $PATH contains:

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/opt/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

The documentation states that after running the pacman commands, one should:

Close MSYS2 and reopen the 64-bit version to make sure the environment picks up GCC.

but this did not make any difference for me.

pico Timers not counting when debugging with picoprobe-cmsis-v1.0.1 and upstream openocd 0.12.0-rc2

My Raspberry Pi Pico's timers are not working the counter is stuck at zero after switicing to the latest release of picoprobe

When It used to work:

followed usual guide from pico c/c++ sdk to compile openocd and picoprobe
have used openocd 0.11.x and the latest uf2 provided (one without cmsis-dap support)

my vscode launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug Pico",
            "request": "launch",
            "type": "cortex-debug",
            "cwd": "${workspaceRoot}",
            "executable": "${workspaceFolder}/target/thumbv6m-none-eabi/debug/learn_pico",
            "preLaunchTask": "build_binary",
            "servertype": "external",
            "gdbPath" : "gdb-multiarch",
            "gdbTarget": "localhost:3333",
            "runToEntryPoint": "main",
            "preLaunchCommands": [
                "monitor init",
                "monitor reset init",
                "monitor halt",
            ],
            "postRestartCommands": [
                "break main",
                "continue"
            ],
        }
    ]
}

timers are working correctly

When it stopped working

with upstream openocd 0.12.0-rc2 (build steps followed: $ ./bootstrap $ ./configure $ make -j4)
and picoprobe-cmsis-v1.0.1

and with the following command to start openocd

openocd -d2 -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c 'adapter speed 10000;'

My timers' counter no longer counts up.

monitor reset command makes them tick again. but

upon using any thing else like in above vscode config preLaunchCommands, they stop counting.

What's happening when Pico Probe is SWD connected to a Pico, circuit is behaving differently...

I've connected an analog circuit which depends on differences in small microampere area to some Pins of the Pico.
Without any connection on the SWD pins it works.
As soon as I connect the Pico Debug Probe with the running Pico, there is some heavy difference happening on the circuit.
So I can not use it at the moment to debug in the productive environment.
Something similar I've seen in my development environment when attaching/removing stuff to/from VBUS and mixing different potentials with same ground, that the debug connection crashed repeatably with reporting a not specified ARM error, but the Debugged Pico itself has no problem and continues. I can also restart the Debug session and it works until there is the next change on bus, like touching ground with a voltmeter.

UART doesn't seem to work

Hello,

I've flashed picoprobe fw to my pico via dropping uf2 file onto presented mass storage. I've noticed picoprobe_info() is disabled by default so I changed that false to true in picoprobe_config.h in expectation to see the "Welcome to picoprobe" message in PuTTY (bitrate 115200). That didn't really happen though, so I changed it for printf, but still no message.
I also wanted to make a little sanity check so I added some LED blinking and that worked.
Would you have an idea what might be going wrong?

Edit:
Not sure if this helps. I've measured SWD with Saleae and the clock speed seemed to be about 1KHz, which is way below. Maybe it could as well be that my board has messed up timing which could also result in non-working UART.