Spark Logic

Black Magic Probe on an stm32f103c8

Rick Kimball

11/07/2017 – I attached a binary that can be loaded onto your blue pill in this post: viewtopic.php?f=37&t=2801

12/3/2016 – You can now contribute to developers of the Black Magic Probe project (which isn’t me) using paypal. Find and click the paypal contribute button here: https://github.com/blacksphere/blackmagic

12/8/2016 – Instead of using this port of Black Magic Probe, it is a lot easier to just compile the PROBE_HOST=stlink and load that onto your bluepill. The bluepill hardware is the same as the stlink v1/v2 hardware. Just follow the steps from the Black Magic Probe software for building and installing the BMP stlink platform. The advantage being, you will get the latest BMP version and you will be able to update future versions just using the USB cable on the bluepill with a program called usb-util. The posts in this thread can be thought of as an interesting read on my journey from bluepill newbie to a somewhat proficient users of it.

The Black Magic Probe is a modern, in-application programmer and debugging software for embedded microprocessors. It allows you to see what is going on ‘inside’ an application running on an embedded microprocessor while it executes. It is able to control and examine the state of the target microprocessor using a JTAG or SWD (Serial Wire debugging) port and on-chip debug logic provided by the microprocessor. The probe connects to a host computer using a standard USB interface. The user is able to control exactly what happens using the GNU source level debugging software, GDB. Read more about it here: https://github.com/blacksphere/blackmagic/wiki

However, the stm32duino crowd here will find the open source Black Magic firmware more appealing than the hardware. The Black Magic Probe firmware can be loaded onto the low cost stm32c8t6 boards you find on eBay. You can then use that clone board with BMP firmware to take the place of an ST-Link programmer. Once the BMP firmware is loaded on a clone board, it provides the ability to upload to the flash of another target board. It does this using a gdb server built into the BMP firmware. This allows for hardware debugging using just arm-none-eabi-gdb without any host server code.

I started with the latest github version of the Black Magic Probe software and added platform support for the stm32f103c8t6 boards you find on ebay. I call it the ‘jc66_coreboard’ platform, as that is the label printed on the silk screen. Any board with the same pin outs should work (See Red Pill Blue Pill post for more info about the hardware). The new platform is based mostly on the already existing stlink platform source with changes to support the different hardware pin outs and features.

The ebay “Red Pill” board loaded with the Black Magic Probe firmware acting like a programmer:
Image
by Rick Kimball, on Flickr

Target board (another “Red Pill” board) connections from the “Red Pill” BMP programmer:
Image

I’ve attached a zip file containing the blackmagic.bin file, the blackmagic elf file, and patch file for the source. ( NOTE: I will fork BMP github code and create a branch with the source changes). For now, just download and unpack the zip and then upload the bin or elf file to your jc66_coreboard.

If you want to build the source yourself, do something like the following:
$ git clone https://github.com/blacksphere/blackmagic
Cloning into 'blackmagic'...
remote: Counting objects: 3463, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3463 (delta 0), reused 0 (delta 0), pack-reused 3461
Receiving objects: 100% (3463/3463), 1.70 MiB | 0 bytes/s, done.
Resolving deltas: 100% (2331/2331), done.
Checking connectivity... done.
$ cd blackmagic
$ unzip ../bmp_jc66_coreboard.zip
Archive: ../bmp_jc66_coreboard.zip
inflating: blackmagic
inflating: blackmagic.bin
inflating: bmp_jc66_coreboard.patch
$ patch -p1 <bmp_jc66_coreboard.patch
patching file src/Makefile
patching file src/command.c
patching file src/platforms/common/cdcacm.c
patching file src/platforms/jc66_coreboard/Makefile.inc
patching file src/platforms/jc66_coreboard/Readme
patching file src/platforms/jc66_coreboard/jc66_coreboard.png
patching file src/platforms/jc66_coreboard/platform.c
patching file src/platforms/jc66_coreboard/platform.h
$ make
$ cd src
$ make install # assuming it go OK, you will have to change the path for the st-write utility to match your system

Replies8

devan Wed Dec 07, 2016 5:08 am

RogerClark wrote:Have you tried changing the VID/PID on the bootloader ?

I presume you can get hold of a copy of the STLink binary that was on some russian forum. It would be easy to use a hex editor to find and change the VID /PID pair as those sorts of things are usually stored close to each other in the binary

RogerClark Wed Dec 07, 2016 5:24 am

@devan

I just noticed what you said about the STLink V1 not doing anything until the bootloader gets a command :-(

OK. So its probably only possible to update boards that have the mass storage version ?

devan Wed Dec 07, 2016 6:27 am

That’s my understanding based on what I’ve seen and what the article said, but I don’t know much about the STLink protocols, since I normally just immediately replace them with open-source debugger firmware.


For some reason ST-Link 2-1 refused to enter DFU mode after I flashed it and just kept booting into the user-code, so make sure that you have another programmer to flash back the original bootloader once you dumped it. No such problem on ST-Link v2. Use at your own risk.

Based on what lujji wrote on the eevblog forum, the “problem” of the V2-1 bootloader running the user code every time is exactly the behavior we want, assuming we can figure out where to jump to rerun the bootloader later.

michael_l Wed Dec 07, 2016 7:39 am

RogerClark wrote:michael_l wrote:Well I guess it must be the hardware because I didn’t flash anything to it. Maybe I accidentally put 3.3V to GND or something.

RogerClark Wed Dec 07, 2016 10:38 am

Guys

Just as a matter of interest, I tried following the instructions on https://lujji.github.io/blog/reverse-en … -firmware/ and changed the binaries in the update jar file so that they were all the f2_3.bin version

This did successfully update, but I dont see any change in the Windows device manager, i.e no mass storage or USB Serial devices, so either that binary only has the stlnk device or the upgrade didnt work correctly

I tried doing the same thing with one of the larger binaries, but the firmware updater would not load it onto my STLink as it would technically not fit in flash.

Looking at that article, it seems to imply that the stlink bootloader is in the lower 0x4000 (16k) which is big for a bootloader, but it would explain how a 49k binary could not fit in a 64k device

I also looked to see if I could move the BMP start location to 0x8004000 and attempt to encrypt the binary and get the STLink updater to install it on one of my unmodified Baite STLink’s, but when I changed the

LDFLAGS = $(LDFLAGS_BOOT) -Wl,-Ttext=0x8002000

michael_l Wed Dec 07, 2016 6:08 pm

Thanks Roger, thats interesting info.

I think I’ve asked this before. Does BMP support printf through SWO in stm32duino? I have a project that uses serial and it would be handy to output debug prints somewhere else but still by using only BMP.

RogerClark Wed Dec 07, 2016 7:48 pm

Micheal

On the BMP you have to wire its serial Tx and Rx pins to the STM32 PA9 and PA10 ( USART 1)
Note. I cant recall if Tx or Rx connects to PA9, but its well documented elsewhere

michael_l Wed Dec 07, 2016 8:33 pm

Thanks, I’ll try that.

Post a reply