Dear community,
I am using PlatformIO with the Pi Pico. I have a problem with the offered debugging solutions,
i.e. Segger and PicoProbe. Segger is prohibitively expensive for a hobbyist and their EDU line is sold out. Picoprobe works but is terribly slow, I widely accepted problem. Especially when debugging bigger projects with a couple 100k it takes forever until the program is uploaded and actual debugging starts. Raspberry foundation is aware of this and supposedly working on a better (faster) picoprobe, but noone knows if and when it will be available. So I am out of good options.
However, there are 2 good other very cheap and/or free options for debugging, unfortunately
Platformio does not support it for the Pico.
- A brilliant chap has developed a much faster picoprobe (upload is 40x faster in tests):
Faster picoprobe ... much faster ... - Raspberry Pi Forums
Problem is I do not know how to integrate this into Platformio .ini file.
The thread linked above describes how to use the faster picoprobe by adding commands
to the launch.json file, but I do not know where to add these commands in platformio.
{
“version”: “0.2.0”,
“configurations”: [
{
“name”: “Pico Debug”,
“cwd”: “${workspaceRoot}”,
“executable”: “${command:cmake.launchTargetPath}”,
“request”: “launch”,
“type”: “cortex-debug”,
“servertype”: “external”,
// This may need to be arm-none-eabi-gdb depending on your system
“gdbPath” : “arm-none-eabi-gdb”,
“gdbTarget” : “\\.\COM23”,
“device”: “RP2040”,
“configFiles”: [
“interface/picoprobe.cfg”,
“target/rp2040.cfg”
],
“svdFile”: “${env:PICO_SDK_PATH}/src/rp2040/hardware_regs/rp2040.svd”,
// runToEntryPoint causes differences in behavour between launch and reset
// so best avoided for this use case.
//“runToEntryPoint”: “main”,
// breakAfterReset means it consistantly stops in the reset handler code
// so we can follow that with some commands to get us to main
“breakAfterReset”: true,
// get_to_main puts a breakpoint at main, gets there, and then remove is
// immediately after flashing. This means that by the time any ram based
// breakpoints are applied the relevant stuff is in RAM.
“postLaunchCommands”: [
“break main”,
“continue”,
“help”,
“help”,
“clear main”,
],
// With breakAfterReset we have a consistent approach so can use the same
// commands to get us to main after a restart…
“postRestartCommands”: [
// “monitor get_to_main”
“break main”,
“continue”,
“help”,
“help”,
“clear main”,
],
}
]
}
I would be very grateful if someone could help me.
- The other option is to use the Black Magic Probe.
I saw that Platformio supports this probe with many MCUs, but unfortunately
not with the PICO. Is there any guide how I could use this probe
with Platformio?
Since the Pico has become so popular (one reason being that it is
widely available unlike other MCUs that are sold out) I think a cheap, fast debugging
option would be of benefit to many users.
Thank you very much in advance and best regards,
Josef Haydn
Wut, but this is the same config file as used the for the regular picoprobe? If you just change the firmware to be better but the OpenOCD configs stay the same, you can debug the Pico as already stated.
Good point. BMP support must be added in the platform code but that can be done rather easily. I’ll have a look at it.
Thank you very much Max and also thank you very much for your other efforts regarding platformio and the Pico. I thought the two picoprobes “normal” and the new “super fast” one have different configurations because the developer of the super fast version had to add some extra commands in json.launch:
“postLaunchCommands”: [
“break main”,
“continue”,
“help”,
“help”,
“clear main”,
],
// With breakAfterReset we have a consistent approach so can use the same
// commands to get us to main after a restart…
“postRestartCommands”: [
// “monitor get_to_main”
“break main”,
“continue”,
“help”,
“help”,
“clear main”,
],
I tried to enter these in the json.launch of the platformio project, but it does not like it, as this file should not really be edited in platformio as I understood. If those commands are the same as in the slow picoprobe config it should work as you say, but it does not. If I just replace the picoprobe.uf2 file on the debug pico with the fast one (which can be downloaded here in compile form, source code is on the same github repo)
https://github.com/essele/pico_debug/releases/download/v0.3/pico-debug.uf2
I get an error message when debugging with platformio. The reason must be that something must be configured differently as in the slow picoprobe in platformio and I thought I can just copy the json.launch file, but platformio does not like it. Unfortunately I do not know enough about platformio works, i.e. how to translate the commands from a “normal” VSCode project config file for the Pico to a platformio project config file, so I am stuck.
As to the Blackmagic Probe: I know it is good practice to support the developers, but I could not find it in the EU. Since many have money issues because of inflation I wanted to give this tip how to very cheaply create your own blackmagic probe (it is open source) with only 2 STLink v2 dongles which are sold for only ca. 9 EUR each on Amazon. How to do this is shown here:
Would be really great if we could find a fast solution for Pico Debugging which is affordable for everyone. I am doing some graphics stuff with LVGL and at the moment I am totally frustrated because upload takes almost a minute, so debugging is no fun at all anymore. I wished I could solve the problem myself but I do not know enough about the inner workings of platformio.
Thanks again and best regards
Josef Haydn
I did some more experimenting and now know that I need to find out how
to translate the attributes of the cortex-debug plugin for VS Code to the platformio debug
settings. The super fast picoprobe works with cortex-debug options and I tried to
find the corresponding settings in platformio.ini but failed.
The cortex-debug options can be found here:
The platformio debug options can be found here:
https://docs.platformio.org/en/stable/projectconf/section_env_debug.html
My problem is that I am already stumbling at the debug port option:
in cortex-dbg this is specified by parameter “gdbTarget”
in platformio I used the parameter debug_port, but this gives me an error.
The super fast picoprobe registers 3 ports, one of it is the debug port
for gdb (normally the middle port number of the 3 ports).
In Windows this is COM30 on my machine.
I tried to enter COM30 or 30 as debug_port in platformio, but this
gives already the first error.
Similarly I would need to find a way to specify the other cortex-debug
options like “postLaunchCommands”, “postRestartCommands”, “breakAfterReset” etc.
I tried e.g. d
debug_init_cmds
debug_extra_cmds
debug_load_cmds
as platformio parameters for “postLaunchCommands” but this does not
work, platformio gives an error.
So my basic problem is: How can I map cortex-debug parameters to platformio.ini
parameters? Is there a guide that explains this or could someone help me please.
The superfast pico probe is really super fast as I have experienced in a cortex-debug
project. It would be lovely if I could also use it in platformio and I am sure it would benefit
many others who cannot afford a Segger J-Link.
Thank you very much in advance
Josef Haydn