Debug Probe fails on RP2040 revision B1

[Gerhard-Vienna]

When my homemade debugger stopped working with 'Picoprobe', I loaded the 'debugprobe' firmware. However, the debugger fails with
Error: Could not connect multidrop rp2040.dap0

I got hold of an original 'debugprobe' and as it worked fine, I assumed it was the pico I was using. So I tried it with different picos, but the result was always negative.

The solution then lay in the output of 'picotoo info -a'.

The picos I used were all revision B1, whereas the original pico probe was revision B2.
Replacing the pico in my homemade debugger with a recently purchased one (B2) solved the problem.

Details:

• OS: Linux, Debian 12

• openocd -v
  Open On-Chip Debugger 0.12.0+dev-gebec9504d (2024-11-25-20:09)
  Downloaded from https://github.com/raspberrypi/openocd.git

• debugprobe:
  sdk version: 2.1.0
  pico_board: pico
  boot2_name: boot2_w25q080
  build date: 20 Dec 2024
  Build attributes: Release
  Downloaded from https://github.com/raspberrypi/debugprobe.git

I'm not sure if the lack of support for older picos is intentional or a bug. In any case, a note in the documentation (Getting Started...) would be appropriate!

[lurch]

I can't think of any obvious reason why it would work on an RP2040B2 but not on a RP2040B1, so pinging @P33M to have a look at this after the Christmas & New Year holidays.

[max22-]

Thank you very much @Gerhard-Vienna ! i've spent all the day trying to find why i got the same error :

Error: Could not connect multidrop rp2040.dap0

I've tried with two diffrent boards, it failed, and it appears that they are revision B0. After having read your message, i've tried with the most recent board i had, which is a revision B2, and it worked on the first try !

(i've tried everything else, checked the wirings multiple times, trying on another distribution, on another pc, i've soldered a custom debug board with thick wires, etc. i was a little bit desperate before seeing your message).

[Gerhard-Vienna]

Thank you max22 for your answer. I thought I was alone with this problem.

We had a similar case in my company where an (admittedly faulty) software ran smoothly on one batch and the error only showed up in another batch. The manufacturer also had no explanation...