Turning RobotDyn Black Pill into a Black Magic Probe
Tags: rust, embedded, solokeys
Published: 2018-12-18 01:53:03

---
title: Turning RobotDyn Black Pill into a Black Magic Probe
published: true
description: 
tags: Rust, embedded, SoloKeys
---

`Actual date: 2018-12-18`

Today, my package from RobotDyn arrived, containing too many things, among them several STM32 ARM Mini Systems (aka "Black Pills"). They look great, cost $2.99, and don't have [the resistor problem](http://wiki.stm32duino.com/index.php?title=RobotDyn_Black_Pill) most "Blue Pills" have. Since they are F103 boards, I will be able to test `mvirkunnen`'s [stm32f103-usb](https://github.com/mvirkkunen/stm32f103xx-usb) implementation, and eventually, hopefully, manage to implement the USB device for the L432 MCU I so sorely need to get the Rust efforts for [SoloKeys](https://solokeys.com) off the ground.

# Turning one of them into a BMP
I followed [this guide](https://medium.com/@paramaggarwal/programming-an-stm32f103-board-using-usb-port-blue-pill-953cec0dbc86), which is referenced to from the [official documentation](https://github.com/blacksphere/blackmagic/wiki/Debugger-Hardware) (search for "use a generic STM32F103 board").

### Observations
- it's built for `PROBE_HOST=stlink` since the same chip is on STM32's Nucleo and Discovery boards as STLink
- I added the initial BMP DFU bootloader `blackmagic_dfu.bin` via my trusty [FTDI breakout](https://www.digitec.ch/de/s1/product/sparkfun-ftdi-basic-breakout-33v-elektronikmodul-5998762), which I probably overpaid. It turns up as `/dev/ttyUSB0`
- on Linux, stm32loader needs root (or I didn't [fix the udev](https://solo.solokeys.io/udev/) properly)
- the pill then enumerated nicely, identifying as `OpenMoko, Inc.`
- however: `dfu-util` refuses to upload `blackmagic.bin` as the F103 says it doesn't have enough flash. but: [this is not true](https://github.com/blacksphere/blackmagic/blob/master/src/platforms/stlink/Flashsize_F103) - the cheaper versions of the chips just claim they have less flash than they do ;) Anyway, running `sudo python stm32_mem.py` then worked
- and finally, `/dev/ttyACM0` (the GDB server) and `/dev/ttyACM1` (a USART line) turned up \o/
- since `cat /dev/ttyACM0` didn't work, this time around I fixed the udev rules:
```
% cat /etc/udev/rules.d/99-black-magic-probe.rules 
# Black Magic Probe (on RobotDyn STM32 ARM Mini System aka "Black Pill")
# Bus 00x Device 0yy: ID 1d50:6018 OpenMoko, Inc.
ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="6018", GROUP="uucp", TAG+="uaccess"
```
- [double-checked](https://github.com/blacksphere/blackmagic/blob/master/src/platforms/stlink/platform.h) that `SWDIO_PORT GPIOB`, `SWDIO_PIN GPIO14`, `SWCLK_PORT GPIOA`, `SWCLK_PIN GPIO5` are still correct


### Outcome

Running

```
nicolas@berta ~/projects % gdb-multiarch -q                                                                                                                                                                       
>>> target extended-remote /dev/ttyACM0                                                                                                                                                                           
Remote debugging using /dev/ttyACM0
>>> monitor
Black Magic Probe (Firmware v1.6.1-224-g14bedcc) (Hardware Version 0)
Copyright (C) 2015  Black Sphere Technologies Ltd.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

>>> monitor help                                                                                                                                                                                                  
General commands:
        version -- Display firmware version info                                                                                                                                                                  
        help -- Display help for monitor commands
        jtag_scan -- Scan JTAG chain for devices
        swdp_scan -- Scan SW-DP for devices
        targets -- Display list of available targets
        morse -- Display morse error message
        assert_srst -- Assert SRST until:(never(default)| scan | attach)
        halt_timeout -- Timeout (ms) to wait until Cortex-M is halted: (Default 2000)
        hard_srst -- Force a pulse on the hard SRST line - disconnects target
        traceswo -- Start trace capture [(baudrate) for async swo]
>>> monitor targets
Available Targets:
No. Att Driver
No usable targets found.
>>> monitor swdp_scan
Target voltage: unknown
Available Targets:
No. Att Driver
 1      STM32F1 medium density
>>> att 1
Attaching to Remote target
```

was a strangely satisfying experience! No more OpenOCD! Hallelujah!

# Next steps
- The L432 Nucleo (and maybe F3DISCOVERY too?) that I have don't expose the pins to connect to the newly created BMP :/ So, I will try next to just put the BMP firmware directly on the Nucleo's own F103, replacing the STLink firmware.
- test, finally, the Rust `usb-device` implementation!