Spark Logic

Black Magic Probe on an stm32f103c8

Rick Kimball Sat May 16, 2015 1:08 am

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

Replies

victor_pv Fri May 29, 2015 12:12 am

Will have to check once I get it here. I may need to cut the traces to some of the duplicated pins (gnd, 3.3 or 5v) and wire them to the MCU pins directly.

RogerClark Fri May 29, 2015 4:43 am

You’d need to connect to PA9 and PA10 on the microprocessor to get Hardware Serial 1, which would be tricky.

I’m still not convinced that converting a STLink to a BMP is the best way to do it.

They are more expensive than a Maple mini, and apart from that they have a USB plug on one end (which I’m not sure is a benefit, as you’d probably need a usb extension cable to get the BMP in the same place on the bench as a board connected via a normal USB cable)

so I suspect flashing a Maple mini to a BMP is probably a better option.

Note. When reflashing a Maple mini, remember that boot1 floats by default, so if you are uploading via serial, you need to tie Boot1 to GND via 1k etc

victor_pv Fri May 29, 2015 3:28 pm

It may not be, but I’m not too concerned about the uart part. I mostly want to get whichever working with GDB in Windows, so if I get the BMP fw in this board, I’ll give it a try to see what’s better, if BMP or ST-Link, then stay with one.

RogerClark Fri May 29, 2015 10:14 pm

Victor

You don’t need to flash BMP to use GDB.

Texane provides the interface between GDB and stlink, which works with these clone boards

I’m thought I’d posted about how to run GDB via st-util , but let me know if you can’t find it and I will write it up again

Rick Kimball Wed Jun 03, 2015 6:40 pm

I finally got around to soldering some pins on my maple mini clone and wiring it up so I can use it with BMP.

Red Pill board configured as a Black Magic Probe, Maple Mini as target:

maple_mini_bmp.jpg
maple_mini_bmp.jpg (218.33 KiB) Viewed 1114 times

Vassilis Thu Jun 04, 2015 8:55 am

I think
PA13 –> (SWDIO)
PA14 –> (SWCLK)

strawberrymaker Thu Jun 04, 2015 10:46 am

PA13 and PA14 are the SWDIO and SWCLK pins of the mcu, they cant be remapped (or?). The SWDIO and SWCLK pins are laid out on PA4 and PA5 and connect to the PA13 and PA14 Pin of the target MCU

~Straw

Rick Kimball Thu Jun 04, 2015 6:00 pm

strawberrymaker wrote:PA13 and PA14 are the SWDIO and SWCLK pins of the mcu, they cant be remapped (or?).

RogerClark Thu Jun 04, 2015 9:55 pm

Rick

I’m not suggesting this as an option, because I agree that if people choose a BMP STLink upload the debug pins should be enabled…

But, If anyone accidentally uploads code which turns the SWD pins into GPIO, you can still upload by running the stlink upload, and then press reset while its waiting to time out.

Obviously this is a pain for normal development, and I wouldn’t recommend it. But it’s what I used when working on the bootloader, because I needed to test that all the GPIO pins were available for the button or the LED

victor_pv Mon Jun 08, 2015 3:26 pm

Rick, I recevied my st-link clone and have been using it fine.
So you think it is better keeping it as st-link?

I understand with BMP you get a server available as soon as you connect the device, while with st-link you need to run texane.
That is a point in favor of BMP. Is there anything that’s better on st-link?

Rick Kimball Mon Jun 08, 2015 3:44 pm

BMP is limited to the chips it knows about. Luckily, for us that is all the stm32F10x chips. The texane stlink host code is also limited to the devices it knows about, which is limited to another set of STM32 devices.

If you pair your stlink device with openocd, you can use it to flash and program a much wider list of chips. I’ve used the stlink device with NXP LPC1114FN28 chips and LPC8XX, and some stm32f0xx chips just sitting on a pcb. The openocd crew is constantly adding support for new chips and jtag/swd devices. The only problem is you need to get a openocd binary, and this might become less of a problem now that the Arduino Zero is using openocd as its upload.

I’m using linux and openocd, I’ve added support for new chips openocd and new programmers didn’t support. The openocd is fairly well organized and adding support for new things usually just involved adding an entry to a table. Eventually, those chips and devices got supported and I could just use the stock code. The texane stuff, is more a hack when it comes to how they handle a lot of the responses to gdb rsp and devices. Although you can certainly get lost using the openocd vs texane. Texane is simple and openocd is more complex but flexible.

I think you have a lot more choices if you just leave it as a stlink device. But if you only plan to use the BMP device with this port. It certainly removes having to deal with either openocd or texane on the host side. All you need is arm-none-eabi-gdb.

-rick

victor_pv Mon Jun 08, 2015 9:41 pm

oh man, no more options… I just want something simple that works at once…
I’ll just leave it as st-link for the time being.

Rick Kimball Sun Jun 14, 2015 4:51 pm

Another small change …

I just tweaked the speed settings on the SWDIO and SWCLK pins. I lowered it from 50MHz to 10MHz. 50 was working fine with my maple mini clone and my red pill/blue pill boards. However, I tried using this with an old stm32vl discovery board. It was failing intermittently. I lowered the speed and those problems went away. I guess it was driving the slew harder than it needed to.

Those value line discovery boards have some issues. It has an STLink V1 interface and they are a pain on linux, as they try and create a mass storage device and linux has issues with how it is done. The target chip is the stm32f100rbt6, a lower price point version of the cortex-m3. It doesn’t have much going for it though. It only has 8k of RAM and runs at 24MHz max, although I was able to run it at 48MHz and it did seem to work. I guess the only good thing about it is a couple of DAC peripherals, and all of its pins are broken out. Oh and yeah, this board is used in the Indiana University Computer Science course:

http://www.cs.indiana.edu/~geobrown/book.pdf

https://github.com/geoffreymbrown/STM32-Template

I pushed my minor changes to the github source.

-rick

Rick Kimball Sun Jun 14, 2015 8:02 pm

I’m trying to score github link brownie points ; )

alex Tue Jul 28, 2015 2:28 am

victor_pv wrote:Rick, I recevied my st-link clone and have been using it fine.
So you think it is better keeping it as st-link?

RogerClark Tue Jul 28, 2015 3:39 am

I have 2 different STLink adaptors, one in an aluminium case which you can slide off over the USB connector

Image

I took a look at the internals and I think the 4 solder pads on the board are for programning it via another Stlink adaptor, as I don’t think they connect to PA9 and PA10 to do a serial upload

If you don’t have another Stlink to program it with, but you have a USB to Serial adaptor, I think you’d need to solder some small wires directly to PA9 and PA10 on the chip, and also put a wire on Boot0

victor_pv Tue Jul 28, 2015 2:22 pm

alex wrote:victor_pv wrote:Rick, I recevied my st-link clone and have been using it fine.
So you think it is better keeping it as st-link?

alex Wed Jul 29, 2015 7:20 am

victor_pv wrote:alex wrote:victor_pv wrote:Rick, I recevied my st-link clone and have been using it fine.
So you think it is better keeping it as st-link?

alex Wed Jul 29, 2015 8:01 am

RogerClark wrote:
I took a look at the internals and I think the 4 solder pads on the board are for programning it via another Stlink adaptor, as I don’t think they connect to PA9 and PA10 to do a serial upload

Sign in to reply