improvement for .vscode+openocd

[WojciechGw]

Improvement to make firmware programming directly from VSCode easier
when the configuration uses two separate Debug Probes connected to the RIA and VGA.

[rumbledethumps]

I get what you're going for but this means I'll be on constant guard duty to never check in my S/N and since everyone else will check in theirs I'll have to guard every PR too. It's why I have a hard rule of no workstation config in my repos - helps to prevent credential leaks too. Can the debugger can switch on something else like contents of flash or RAM?

[WojciechGw]

Of course, you are right. I understand and support your position and the rule you described.

Perhaps instead of creating a pull request, I should have posted this as a topic in https://github.com/orgs/picocomputer/discussions. Someone involved in building firmware for the RP6502 might be interested in it.

While trying to make my life easier and avoid mistakes about which Pico board I am flashing the built firmware to, this is the solution I have found so far. I am still looking for other ways to avoid having to add workarounds like this to my fork every time.

Before the solution I presented, I used to add two additional tasks to .vscode/tasks.json: Flash RIA and Flash VGA. That also solved the problem.

However, without exposing anyone to the risk of leaking private data, perhaps you could add a non-disruptive change: pass the CMAKE_LAUNCH_TARGET variable to the Flash task.

If someone wants to use the solution I presented, they would have to modify their own cmsis-dap.cfg file, which is independent of your repo. If they do not do that, they can simply continue switching the cable between the RIA and VGA.

[WojciechGw]

To answer your question: after reviewing the OpenOCD documentation, it seems to me that, at least for now, this is the only solution.

[WojciechGw]

from my notepad (own thoughts and fragments of discussions with different AIs) : maybe is the other way, but there is no better fully logical method than stable identification of the specific probe, or the physical USB path.

In this repo both targets (rp6502_ria_w, rp6502_vga) are Pico 2/RP2350, so OpenOCD cannot distinguish them by chip type or by the firmware file alone. From OpenOCD’s point of view, the “right microcontroller” is the one connected to the selected Debug Probe. If two identical Debug Probes are connected at the same time, one of them must be selected somehow.

Possible alternatives to adapter serial:

1. Physical USB location: OpenOCD supports adapter usb location ..., meaning probe selection by USB topology. This can work if the probes always stay plugged into the same USB ports/hubs. It is less portable and more fragile than using the serial number.

2. Connect/forward only one probe: for example, under WSL, use usbipd attach only for the Debug Probe connected to RIA or only for the one connected to VGA. Then OpenOCD does not need to choose between two probes.

3. Different probe types / VID:PID / product name: in theory OpenOCD can filter by USB VID/PID or product name, but with two Raspberry Pi Debug Probes of the same type this usually does not help, because they are identical except for the serial number.

4. External SWD switch / physical routing: you can use one Debug Probe and switch SWDIO/SWCLK to RIA or VGA with a hardware switch or multiplexer. Then the selection is made in hardware, not by serial number.

What I cannot really do is tell OpenOCD: “flash RIA because I selected target rp6502_ria_w”, if both probes are available and there is no mapping from target to a specific probe/port. OpenOCD does not know the board’s role in the device; it only sees a CMSIS-DAP adapter and an RP2350 behind it.

Conclusion: if both Debug Probes are connected at the same time, adapter serial is the most stable solution. adapter usb location is a real alternative, but it is less resistant to cable/hub changes.

[WojciechGw]

Codex answer me as follows :

The debugger/Pico extension/OpenOCD must first select a Debug Probe before it can read anything from the microcontroller over SWD. Only after selecting a probe can it connect to the RP2350 and read flash, RAM, or registers. So firmware contents or RAM contents cannot be the initial criterion for selecting the probe, because they are only available after that selection has already been made.

But - one workaround seems to be possible:

1. a script enumerates all Debug Probes,
2. connects to each one in turn,
3. reads some marker from the target, for example a flash address, unique ID, or firmware signature,
4. chooses the probe behind which the expected microcontroller is found,
5. only then runs program ... verify reset exit.

But that would be custom script logic, not the standard behavior of the Pico Debug task/OpenOCD. It also has limitations: the marker must already exist, RAM after reset is usually not a reliable identifier, and if the wrong or empty firmware is currently flashed, identification by firmware contents stops being dependable.

In practice, for two identical Pico 2 boards, the best criteria are still external to the target:

• Debug Probe serial number,
• physical USB port (adapter usb location),
• connecting only one probe,
• hardware SWD switch.

So: the debugger itself cannot reliably switch between probes based on flash/RAM contents without first connecting to each probe and adding extra scripting.

[WojciechGw]

Was your question meant to be rhetorical because you solved it differently?

[rumbledethumps]

I haven't spent any time on this. I spend less than 5 minutes a year swapping cables . It going to take a lot longer than that to develop a solution and maintain it.

You could ask on the Raspberry Pi Pico forums or the OpenOCD mailing list for ideas.