search

raspberrypi / openocd

Other
146 stars 89 forks source link

Using a Pico W for a picoprobe not working #76

Closed d-adamson closed 1 year ago

d-adamson commented 1 year ago

I have been naively trying to use a PICO W for my picoprobe. However, it does not appear to work properly. See below for detailed error messages.

I did some investigating and found the following: In the driver file picoprobe.c (line 33), the PID is hardcoded for a regular pico.

define PID 0x0004 / Picoprobe /

However, the PID for the PICO W is 0x000C. I think this may be what is causing the device not to be found.

Command & Response (also tested using sudo and got the same output) $ openocd -s ~/pico/openocd/tcl -f interface/picoprobe.cfg -f target/rp2040.cfg

Open On-Chip Debugger 0.11.0-g8e3c38f (2023-01-24-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' 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.

P33M commented 1 year ago

Which instruction document are you following?

d-adamson commented 1 year ago

Getting started w Raspberry Pi Pico C/C++ development ... downloaded from the website: v2.0 01 Dec 2022.

Below is the section of code. The PID is hard-coded for the standard pico (0x0004), and not the pico w (0x000C).

Here is my device info VID:PID=0x2e8a:0x000c, serial=E6614103E77D7B37

~/pico/openocd/src/jtag/drivers/picoprobe.c

...

include "libusb_helper.h"

define VID 0x2E8A / Raspberry Pi /

define PID 0x0004 / Picoprobe /

...

P33M commented 1 year ago

Which website? Please provide a URL.

lurch commented 1 year ago

https://github.com/raspberrypi/usb-pid says that PID 0x0004 is "Raspberry Pi PicoProbe" and PID 0x000C is "Raspberry Pi RP2040 CMSIS-DAP debug adapter", so I think your comments about Pico W are just a red herring.

I see in your original post you have -f interface/picoprobe.cfg -f target/rp2040.cfg but page 66 of https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf (which is the same v2.0 that you claim you're using) says to use -f interface/cmsis-dap.cfg -f target/rp2040.cfg.

d-adamson commented 1 year ago

@P33M Here is the URL. (https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf)

@lurch Thanks. I didn't know about this document https://github.com/raspberrypi/usb-pid

Yes, I've tried using the instructions on page 66, but I had to add the adapter speed command as follows $ openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000"

With this I can get GDB running from the command line, but not from VS Code. 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, but the debugger is expecting port 3333. I cannot find where this command is being generated. 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 in the command line interface.

In any case, I will receive a regular pico (non WiFi) in a couple of days to use as the picoprobe, and I think most of these issues will go away. Originally, I purchased a 3-pack of pico W devices, and I just assumed everything would work the same as for the regular pico (except, of course, for the added wifi functionality).

Assuming using a regular pico this corrects the issues, it would be nice to either

In any case, I'll report back what I learn.

P33M commented 1 year ago

The interface protocol selected must match what's on the picoprobe (both the setup instructions and published picoprobe firmware match, regardless of whether you're using a picoW or regular pico), but gdb->openocd timeouts are merely a result of configuration differences.

The command is generated internally by the cortex-debug plugin unless config options are overridden in .vscode/launch.json. Please post your launch.json file.

d-adamson commented 1 year ago

I've tried several. However, this is the launch.json file that seems to have gotten the furthest using cmsis-dap.cfg with some commands to set the search directory, the adapter speed and the port number.

{ "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" : "gdb-multiarch", "device": "RP2040", "searchDir":["~/pico/openocd/tcl"], "openOCDLaunchCommands": ["adapter speed 5000", "gdb_port 3333"], "configFiles": [ "interface/cmsis-dap.cfg", "target/rp2040.cfg" ], "svdFile": "${env:PICO_SDK_PATH}/src/rp2040/hardware_regs/rp2040.svd", "runToMain": true, // Work around for stopping at main on restart "postRestartCommands": [ "break main", "continue" ] } ] }

Terminal Output openocd -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s ~/pico/openocd/tcl -f /home/dadamson/.vscode/extensions/marus25.cortex-debug-1.6.10/support/openocd-helpers.tcl -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000" -c "gdb_port 3333" Open On-Chip Debugger 0.11.0-g8e3c38f (2023-01-24-14:28) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html CDRTOSConfigure 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 adapter speed: 5000 kHz

Info : Listening on port 50001 for tcl connections Info : Listening on port 50002 for telnet connections Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6614103E77D7B37 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 : 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 Info : accepting 'gdb' connection on tcp/3333 Info : RP2040 B0 Flash Probe: 2097152 bytes @10000000, in 512 sectors

Info : New GDB Connection: 1, Target rp2040.core0, state: halted undefined debug reason 8 - target needs reset Warn : Prefer GDB command "target extended-remote 3333" instead of "target remote 3333" Info : dropped 'gdb' connection shutdown command invoked [2023-01-31T21:07:41.636Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session closed GDB server session ended. This terminal will be reused,

Debug Console Output: Cortex-Debug: VSCode debugger extension version 1.6.10 git(0458417). Usage info: https://github.com/Marus/cortex-debug#usage Reading symbols from objdump-multiarch --syms -C -h -w /home/dadamson/mypico/projects/vs_debug/build/vs_debug.elf Reading symbols from nm-multiarch --defined-only -S -l -C -p /home/dadamson/mypico/projects/vs_debug/build/vs_debug.elf Launching GDB: gdb-multiarch -q --interpreter=mi2 1-gdb-version Launching gdb-server: openocd -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s ~/pico/openocd/tcl -f /home/dadamson/.vscode/extensions/marus25.cortex-debug-1.6.10/support/openocd-helpers.tcl -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000" -c "gdb_port 3333" Please check TERMINAL tab (gdb-server) for output from openocd Finished reading symbols from objdump: Time: 13 ms Finished reading symbols from nm: Time: 16 ms -> =thread-group-added,id="i1" -> =thread-group-started,id="i1",pid="42000" -> &"\nwarning: "

warning: -> &"No executable has been specified and target does not support\ndetermining executable automatically. Try using the \"file\" command." No executable has been specified and target does not support determining executable automatically. Try using the "file" command. -> &"\n"

-> =thread-created,id="1",group-id="i1" -> =thread-created,id="2",group-id="i1" -> &"\nwarning: "

warning: -> &"multi-threaded target stopped without sending a thread-id, using first non-exited thread\n" multi-threaded target stopped without sending a thread-id, using first non-exited thread -> ~"0x100011b4 in ?? ()\n" -> *stopped,frame={addr="0x100011b4",func="??",args=[],arch="arm"},thread-id="1",stopped-threads="all" mi2.status = stopped Program stopped, probably due to a reset and/or halt issued by debugger -> ~"GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1\n" -> ~"Copyright (C) 2022 Free Software Foundation, Inc.\n" -> ~"License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law." -> ~"\nType \"show copying\" and \"show warranty\" for details.\n" -> ~"This GDB was configured as \"x86_64-linux-gnu\".\n" -> ~"Type \"show configuration\" for configuration details.\n" -> ~"For bug reporting instructions, please see:\n" -> ~"https://www.gnu.org/software/gdb/bugs/.\n" -> ~"Find the GDB manual and other documentation resources online at:\n http://www.gnu.org/software/gdb/documentation/." -> ~"\n\n" -> ~"For help, type \"help\".\n" -> ~"Type \"apropos word\" to search for commands related to \"word\".\n" -> 1^done 0x100011b4 in ?? () 2-gdb-set mi-async on -> 2^error,msg="Cannot change this setting while the inferior is running." 3-interpreter-exec console "set print demangle on" Failed to generate gdb commands: Cannot change this setting while the inferior is running. (from gdb-set mi-async on) Cannot change this setting while the inferior is running. at i (/home/dadamson/.vscode/extensions/marus25.cortex-debug-1.6.10/dist/debugadapter.js:2:151139) at handlers. (/home/dadamson/.vscode/extensions/marus25.cortex-debug-1.6.10/dist/debugadapter.js:2:151633) at /home/dadamson/.vscode/extensions/marus25.cortex-debug-1.6.10/dist/debugadapter.js:2:138971 at Array.forEach () at b.onOutput (/home/dadamson/.vscode/extensions/marus25.cortex-debug-1.6.10/dist/debugadapter.js:2:138404) at b.stdout (/home/dadamson/.vscode/extensions/marus25.cortex-debug-1.6.10/dist/debugadapter.js:2:137821) at Socket.emit (node:events:526:28) at addChunk (node:internal/streams/readable:315:12) at readableAddChunk (node:internal/streams/readable:289:9) at Readable.push (node:internal/streams/readable:228:10)

d-adamson commented 1 year ago

There is joy today! I received a regular pico (non-wifi) and connected it as the picoprobe. Used the picoprobe.uf2, launch.json & settings.json as specified in the getting started doc. All is working now both at the command line as well as in VS Code.

See

https://github.com/raspberrypi/openocd/issues/76#issuecomment-1415978721

aallan commented 1 year ago

I don't believe there should be any difference between a Pico and Pico W when it comes to using Pico Probe, none of the pins used are pulled elsewhere on Pico W. They should work the same.

d-adamson commented 1 year ago

@aallan

That's what I thought initially too, but if you look in the source code at the following, the picoprobe driver is hardcoded for the pico (PID 0x0004), not the pico wifi (PID 0x000C).

~/pico/openocd/src/jtag/drivers/picoprobe.c

...

include "libusb_helper.h"

define VID 0x2E8A /* Raspberry Pi /

define PID 0x0004 / Picoprobe */

aallan commented 1 year ago

That is not an issue, see @lurch's reply above.

https://github.com/raspberrypi/usb-pid says that PID 0x0004 is "Raspberry Pi PicoProbe" and PID 0x000C is "Raspberry Pi RP2040 CMSIS-DAP debug adapter", so I think your comments about Pico W are just a red herring.

I see in your original post you have -f interface/picoprobe.cfg -f target/rp2040.cfg but page 66 of https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf (which is the same v2.0 that you claim you're using) says to use -f interface/cmsis-dap.cfg -f target/rp2040.cfg.

lurch commented 1 year ago

To clarify (and I'm sure @P33M will correct me if I'm wrong) I believe the PID of 0x0004 was for the "old" version of the picoprobe UF2 using the original (custom?) picoprobe interface (hence the -f interface/picoprobe.cfg argument to openocd), but the PID of 0x000C is for the "new" version of the picoprobe UF2 using the CMSIS-DAP protocol (hence the -f interface/cmsis-dap.cfg argument to openocd). All of this is entirely orthogonal to the differences between Pico and Pico W.

d-adamson commented 1 year ago

Interesting. So the PID follows the firmware (*.uf2) and not the actual hardware? I missed that detail in the earlier post.

Any ideas what the solution may be? Has anyone successfully tested a pico w as the picoprobe?

d-adamson commented 1 year ago

I'll do a test later today. I'll have a project that is running successfully with the picoprobe (regular pico) and then swap in a pico w. I won't change any other parameters, config files, etc., and then I'll post the output of both.

Maybe I started down a false path and got myself confused (it happens), but hopefully this test should help clarify things.

lurch commented 1 year ago

So the PID follows the firmware (*.uf2) and not the actual hardware?

Correct. There's no "settings" or "parameters" inside the RP2040, so when the chip first boots up it doesn't even know if it's on a Pico board, a Pico W board, or some other 3rd-party RP2040 board.

d-adamson commented 1 year ago

SOLUTION

Well, I just ran the test and I confirm that picoprobe (from within vs code) is indeed working with both a pico and a pico w.

You guy are right, I went down a false path somewhere. I should have run this test earlier to confirm what I thought was the solution.

My apologies. I'll amend my comments.

pico_output.txt picow_output.txt