Turning RobotDyn Black Pill into a Black Magic Probe

nickray — Tue, 18 Dec 2018 01:53:03 +0000

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 most "Blue Pills" have. Since they are F103 boards, I will be able to test mvirkunnen's stm32f103-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 off the ground.

Turning one of them into a BMP

I followed this guide, which is referenced to from the official documentation (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, which I probably overpaid. It turns up as /dev/ttyUSB0
on Linux, stm32loader needs root (or I didn't fix the 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 - 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 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!

Rustic OLED on the Nucleo

nickray — Tue, 18 Dec 2018 01:52:04 +0000

Actual date: 2018-12-17 and 2018-12-18

Since my USB device efforts have not led anywhere so far, I diverted my efforts to get an OLED up and running, still on the STM32L4 platform. Eventually, it will be nice to have a Solo key with an integrated display!

Scott Mabin recently added I2C support to his HAL, so I got everything ready quickly. It DID NOT WORK!!!!

Well. First, I bought a very cheap soldering iron and did a horrible job (first solder experience in over two decades) of attaching the pins to my 0.91" 128x32 OLED (with an SSD1306 chip). Still, did not work!

Then, I discovered the 0.96" 128x64 OLED with the same chip was already pre-soldered... again, DID NOT WORK!

(...)

The next day, I finally followed both Conor's and Scott's advice in trying different I2C addresses. A quick search suggested using 0x78 (which is 2*0x3c, which all the data sheets mention) for cheap Chinese clones such as mine, and ta-daa! Success!

Further outcome of non-immediate success

I want this soldering iron
I nearly want this oscilloscope
I watched way too much eevblog episodes
I ordered more (cheap) stuff...
My girlfriend is calling me nutty professor again :D