Debugging with Black Magic probe on VSCode/macOS

First, apologies that I really don’t know much about GDB. Setting up toolchains is not my expertise, and generally I don’t think too much about how the debugger actually works, I just use it. PlatformIO seems to be just about as set-it-and-forget-it as embedded development gets these days, but alas, it’s not QUITE foolproof.

So I’ve got VSCode set up with PlatformIO on a macOS Mojave VM (to keep environment sanity until I set the toolchain up natively). I’m trying to debug a BluePill STM32F103.

Everything seems to work just dandy with minimal overhead, using an ST-LinkV2.

I’m trying to get a Black Magic probe working, since ultimately I’d like to use that going forward for the sake of supporting other targets. That has proved more difficult. Here’s my platformio.ini:

platform = ststm32
board = bluepill_f103c8
framework = arduino

;debug_tool = stlink
;upload_protocol = stlink

debug_tool = blackmagic
upload_protocol = blackmagic
debug_port = /dev/cu.usbmodemDFCEBEE51
upload_port = /dev/cu.usbmodemDFCEBEE51

When I click Go on “PIO Debug”, compilation goes smoothly:

Linking .pioenvs/bluepill_f103c8/firmware.elf
Checking size .pioenvs/bluepill_f103c8/firmware.elf
Memory Usage ->
DATA:    [          ]   1.3% (used 272 bytes from 20480 bytes)
PROGRAM: [=         ]  10.2% (used 6692 bytes from 65536 bytes)
Building .pioenvs/bluepill_f103c8/firmware.bin
=============================================== [SUCCESS] Took 27.92 seconds ===============================================

Terminal will be reused by tasks, press any key to close it.

But over in debug console, just kinda… nothing happens:

Checking size .pioenvs/bluepill_f103c8/firmware.elf
Memory Usage ->
DATA:    [          ]   1.3% (used 272 bytes from 20480 bytes)
PROGRAM: [=         ]  10.2% (used 6692 bytes from 65536 bytes)
========================= [SUCCESS] Took 3.13 seconds =========================
Reading symbols from /Users/alexw/Documents/PlatformIO/Projects/BlinkyTest/.pioenvs/bluepill_f103c8/firmware.elf...
PlatformIO Unified Debugger >
PlatformIO: Initializing remote target...

Is my platformio.ini config wrong?

From Black Magic Probe — PlatformIO latest documentation

Black Magic Probe has 2 serial ports: UART and GDB. We will need “GDB” port.

Do you see these two ports? Did you try the other one?

I didn’t see two ports, but the one I did see had the same name as the GDB port when I connected on the host.

That said, now that I’m trying to retrace my steps and A/B compare with the ST-Link (DOES work in the VM, on PIO/VSCode), I can’t get ANY of the BMP ports to show up. The device itself appears in system info, but something is wrong at the OS level. I begrudgingly have to assume it’s nothing to do with PIO or my configuration, yet.

I’ll report back once I can at least get the BMP to show up reliably in the guest.

I took it a step further and tried the same thing in a Ubuntu 18.04 VM (also Parallels). /dev/ttyACM0 and /dev/TTYACM1 both show up, but GDB can’t target extended-remote /dev/ttyACMx either of them. If I try to connect to /dev/ttyACM0, nothing happens - I just never get a (gdb) prompt. I can’t even ctrl-C out. If I try /dev/ttyACM1, eventually there’s a timeout:

Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response

and then at least I can ctrl-c.

So long and short of it, it seems like Black Magic Probes simply don’t work under VMs. And apparently I’m not the first one, but close, to find out: USB config error Docker-Machine / VirtualBox · Issue #416 · blackmagic-debug/blackmagic · GitHub

Could you make a photo with your wiring connection?

Sure. This is with the BMP firmware loaded on an STLink V2 clone.
I do have a real BMP board on the way, for fun.

FWIW: the real probe arrived, and it also has problems enumerating both (or any) serial ports in a VM. So it’s clearly something to do with the firmware’s USB implementation.

So, does real BMP work?

No. The serial ports still fail to register reliably/at all despite USB enumeration, so I can only conclude that it’s a bug in the BMP firmware with the implementation of USB on the STM32 that doesn’t play nicely with virtual machines.

But also, have a look at this thread:

I can’t seem to get anything besides a J-Link to work reliably, with an Atmel SAMD target.