Unable to swdp_scan since 1.9.0rc1

[chaten]

When updating my BMP to rc1, I am unable to attach my RP2040 board.

rc0 seems to work, so there looks to be a regression between the two, perhaps related to Fixed the Cortex-M SWD attach regression that occurs when there is a delay between scan and attach [dragonmux]

Found: Black Magic Probe  v1.8.2
  Serial: 98B71791
  Port:  1-2
Erasing flash...
Flashing...
 100% |██████████████████████████████████████████████████| 106.24KiB/106.24KiB [4.34KiB/s 23s]
Black Magic Probe successfully rebooted into firmware version v1.9.0-rc1
mrc@mrc-devbox ~/Downloads $ arm-none-eabi-gdb
GNU gdb (Gentoo 12.1 vanilla) 12.1
(gdb) monitor tpwr enable
Enabling target power
(gdb) monitor swdp_scan
Target voltage: 3.2V
SW-DP scan failed!
Failed
(gdb) monitor swdp_scan
Target voltage: 3.3V
SW-DP scan failed!
Failed
(gdb) monitor swdp_scanQuit
(gdb) quit
mrc@mrc-devbox ~/Downloads $ bmputil flash blackmagic-native-v1_8_2.elf 
Found: Black Magic Probe v1.9.0-rc1
  Serial: 98B71791
  Port:  1-2
Erasing flash...
Flashing...
 100% |██████████████████████████████████████████████████| 102.16KiB/102.16KiB [4.32KiB/s 22s]
Black Magic Probe successfully rebooted into firmware version  v1.8.2
mrc@mrc-devbox ~/Downloads $ arm-none-eabi-gdb
GNU gdb (Gentoo 12.1 vanilla) 12.1
(gdb) monitor tpwr enable
Enabling target power
(gdb) monitor swdp_scan
Target voltage: 3.2V
Available Targets:
No. Att Driver
 1      Raspberry RP2040 M0+
 2      Raspberry RP2040 M0+
 3      Raspberry RP2040 Rescue(Attach to reset!) 
(gdb) quit
mrc@mrc-devbox ~/Downloads $ bmputil flash blackmagic-native-v1_9_0-rc0.elf 
Found: Black Magic Probe  v1.8.2
  Serial: 98B71791
  Port:  1-2
Erasing flash...
Flashing...
 100% |██████████████████████████████████████████████████| 106.29KiB/106.29KiB [4.34KiB/s 23s]
Black Magic Probe successfully rebooted into firmware version v1.9.0-rc0
mrc@mrc-devbox ~/Downloads $ arm-none-eabi-gdb
GNU gdb (Gentoo 12.1 vanilla) 12.1
(gdb) monitor tpwr enable
Enabling target power
(gdb) monitor swdp_scan
Target voltage: 3.2V
Available Targets:
No. Att Driver
 1      Raspberry RP2040 M0+
 2      Raspberry RP2040 M0+
 3      Raspberry RP2040 Rescue (Attach to reset!) 
(gdb) 

[dragonmux]

Thanks for the report, chaten. We did not change any of the SWD bitbanging or scan code in that PR, so this should be unrelated as you're getting a failure to scan rather than a failure to attach.

Using the rc1 firmware, could we ask you to build BMDA via make PROBE_HOST=hosted HOSTED_BMP_ONLY=1 ENABLE_DEBUG=1, run the resulting binary up as src/blackmagic -v 5 and use it (by doing tar ext :2000 instead of your normal target command) to get a log of what's going on during scan please? That would help with both reproducing this locally and understand what's going on

We will try to reproduce this locally in the mean time.

[chaten]

I've attached the output as it is quite long.

output.txt

[dragonmux]

You'll be happy to know that we've been able to reproduce this locally. The behaviour being seen is tangentially related to the attach issue fix - BMD gets a no-response response repeatedly and tries to recover, unsuccessfully, leading to this no-scan behaviour. We'll work on a fix while trying not to break the recovery behaviour

[dragonmux]

So, a little update having done some deeper diving. This is actually exercising two(!) bugs which are nicely demo'd by this logic trace capture:

To explain a little: The first request shown is an RDBUFF which BMP is interpreting to have given no-response despite actually being given an OK - this is the main part of the complaint, but actually the secondary bug; We then do a line reset to clear the no-response state the firmware thinks it has, and re-read the device ID to ensure the device came back; After that completes, the firmware tries (and mucks up) to send a target selection command to re-select the target (this does result in a real no-response), and then we try to read the CTRL/STAT register and when that fails, things go completely pear-shaped.

The following two screenshots provide some more detail on those failing requests which constitute the primary bug that's preventing recovery from working correctly:

We will endeavour to fix first the recovery fault, and then the bug that's causing it to think it needs to do recovery, and will keep this issue appraised.

[dragonmux]

It is not a complete fix (it only addresses the recovery process failing), but please give fix/dpv2-swd-regression a try which should at least allow scan to complete and you to attach.

[dragonmux]

Root cause found - scan was not setting the DP version, resulting in incorrect protocol recovery. The fix branch allows successful scan and attach on RP2040 for us, so we'll open the fix PR now, but please let us know if the issue is fixed for you too.