F072 based probe hangs when restarting target from VS Code

[jbussmann]

Goal:
Build a debug probe to embed into prototype projects using the smallest possible footprint. Of the supported platforms f072/f3 seem to offer the smallest chips using WLCSP49 packages. I went for the f072 platform for simplicity and lower price.

Setup:
I have 2 Bluepill clones at hand: One with a genuine STM32F103C8T running Black Magic Firmware v1.9.0 compiled for swlink platform and one with a STM32F072C8U running Black Magic Firmware v1.9.0 compiled for f072 platform. Firmware is precompiled from here. The target is a nRF52840 on an Arduino Nano 33 BLE. PC side is GDB command line or VS Code with Cortex-Debug extension on Windows.

Issue:
When using the f072 probe in VS Code and trying to restart or reset the target, the probe crashes. It becomes unresponsive and all LEDs turn off. Resetting the probe lights up the LED but only replugging USB makes it connectable again. Everything else works: stepping and breaking in VS Code works, using GDB command line start and run works and using the F103 probe also fully works in VS Code. The last output of the debug console in VS Code is as follows

64-interpreter-exec console "SoftwareReset"
-> =cmd-param-changed,param="language",value="c"

I can reproduce the exact same behaviour and output by typing SoftwareReset in the debug console.

Workaround:
Only when gathering all the details for this issue, I discovered that I can type start and run into the debug console in VS Code. This gives the desired result of restarting the target with and without break at main.

So what does this SoftwareReset do and how does the firmware handled it differently depending on the platform? It seems to be an issue of the firmware and not the VS Code debug extension as the swlink firmware can handle this command correctly. Is there any documentation on f072/f3 platform available? Does anyone even have experience with this firmware any anyone ever built this? I am in the process of setting up the toolchain on Linux so I can compile the firmware myself. Reason being my intention to modify pinout for easier fanout and possibly even omit the crystal for further footprint reduction, as those chips support crystal-less USB. Any help is much appreciated, thank you for supporting this awesome project!

[dragonmux]

Please give latest main a try as #1405 contains a fix to BMD's probe<->GDB detach and reattach behaviour that was causing issues with probes crashing and similar. This fix will be released as part of a v1.9.1 bugfix release in the near future

Regarding software reset, that we aren't sure about - going to have to dive into the Cortex-Debug extension and see what that's about. If you could provide us with your .vscode/launch.json so we can see how you've configured the extension, that would be fantastic

[jbussmann]

Thank you for the suggestion and the explanation. When digging deeper, I found that not the reset itself is the problem but modifying memory, which the reset does by writing into a core register. Trying to modify peripheral registers results in the same behaviour. Please change the title if you consider it necessary to reflect this insight.

Meanwhile I have set up the toolchain and compiled the v1.9.0 release commit with the same result. Compiling the latest main fixed the problem. I switched several times back and forth to rule out possibly bad cable connections. Therefore I consider this fixed.

Also would you mind answering some of my questions regarding existence of documentation and hardware of the f072/f3 platform? Some things seem oddly specific (like switched USART pins), how or by whom did this platform came into existence?

Following is the relevant launch configuration. Also I found this very old and thus likely unrelated issue. Let me know if you wish further debug output in working or non working state. Or if you would like me to test pre and post of mentioned commit, to verify this being the fix.

"name": "BMP Debug Port 34",
"cwd": "${workspaceFolder}",
"executable": "projects/blinky/_build/nrf52840_xxaa.out",
"request": "attach",
"type": "cortex-debug",
"device": "nrf52",
"runToEntryPoint": "main",
"servertype": "bmp",
"BMPGDBSerialPort": "\\\\.\\COM34",
"svdFile": "nRF5_SDK_17.1.0/modules/nrfx/mdk/nrf52840.svd",
"showDevDebugOutput": "raw"

[dragonmux]

Also would you mind answering some of my questions regarding existence of documentation and hardware of the f072/f3 platform? Some things seem oddly specific (like switched USART pins), how or by whom did this platform came into existence?

Certainly, those two platforms came about as a result of our splitting them out from PR #924 in PRs #1037, #1038 and #1191 which are modifications of Uwe Bonnes' work - beyond that we actually don't have much history on them much less what they really target because he never wrote any of that up. They were merged because they seem useful (several people are using the F072 platform for a variety of their own custom probe hardware) and we didn't want them in the same PR as a major new target architecture.

Given the behaviour you've described above, we're happy that this is fixed and will now close the issue as resolved - if further things need to happen, let us know and we can re-open the issue