Debugging an RP2040 in openocd doesn't work

[jonathanherbstgrapple]

Here is the output I'm getting.

Info : Using CMSIS-DAPv2 interface with VID:PID=0x1209:0x4853, serial=dc63aca893923e36ef4014
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: SWO streaming trace supported
Info : CMSIS-DAP: FW Version = 7a0d7c4-modified
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, DLPIDR 0x00000001
Info : Read incorrect DLPIDR 0xf0000001 (possibly CTRL/STAT value)
...
Info : Read incorrect DLPIDR 0xf0000001 (possibly CTRL/STAT value)
Error: Failed to connect multidrop rp2040.dap1

I did some digging and I think this is at least because openocd uses an swd sequence for LINE_RESET and it doesn't look like swd sequences are supported in the firmware yet.
https://github.com/foss-for-synopsys-dwc-arc-processors/openocd/blob/master/src/target/adi_v5_swd.c#L171

[jonathanherbstgrapple]

I dug a bit farther into this and it looks like line reset is actually an swj sequence in openocd and not an swd sequence like I originally thought. I observed the swd pins with a logic analyzer and sure enough it's generating a line reset.

I also tried the same thing with a raspberry pi probe, which works, to compare the two signals and I have some leads to look into.

1. There is an extra transfer the raspberry pi probe sends, that the rusty probe doesn't send. I think it's a TARGETSEL command, but the target doesn't respond to it anyway. Maybe openocd treats the rusty probe differently than the raspberry pi probe for some reason, which is causing the difference in functionality.
   
2. The output from the rusty probe is slower than the raspberry pi probe and the swj sequence is bit-banged and is inconsistent sometimes so maybe the line reset isn't working on the target.
   

Just some thoughts at the moment, I might see if I can get a pio version of swj sequence command working.