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

Replies20

RogerClark Thu Nov 05, 2015 11:25 pm

LOL

I was just about to post this

target_add_ram(t, 0x20000000, 0x8000);

But I’ll see what you did ;-)

RogerClark Thu Nov 05, 2015 11:29 pm

Edit

I pulled your changes

I thought it was 32k ram ???

Not that it will affect the upload

RogerClark Thu Nov 05, 2015 11:39 pm

Arrggg

Made and flashed it but forgot to set

PROBE_HOST=jc66_coreboard all

So USB didnt work

So I’ll have to reconnect it all and reflash it again

PS. It a rare event but I”ve turned on IRC ;-)

RogerClark Thu Nov 05, 2015 11:56 pm

OK

Some progress

Its now recognised as the NRF51

(gdb) monitor swdp_scan
Target voltage: Not Implemented!
Available Targets:
No. Att Driver
1 Nordic nRF51
(gdb) attach 1
Attaching to Remote target
0x00002fa0 in ?? ()

Rick Kimball Fri Nov 06, 2015 12:02 am

you can ‘load’ .elf files. to upload a .hex you need to use ‘restore’

(gdb) help restore
Restore the contents of FILE to target memory.
Arguments are FILE OFFSET START END where all except FILE are optional.
OFFSET will be added to the base address of the file (default zero).
If START and END are given, only the file contents within that range
(file relative) will be restored to target memory.
So …
(gdb) restore blink.hex

Rick Kimball Fri Nov 06, 2015 12:12 am

RogerClark wrote:PS. It a rare event but I”ve turned on IRC ;-)

RogerClark Fri Nov 06, 2015 12:16 am

lol

Command is erase_mass not mass_erase

Sorry, its my dyslexia (well kind of, as I’m not really dyslexic )

I’ll see if it gets erased

Edit

address 0 seem to have ffff

RogerClark Fri Nov 06, 2015 12:24 am

umm

Seems to load the ELF file OK and the memory at 0x01c000 seems to look like the start of the bin file that was also created by the IDE

Ah.

Looks like it is kind of working.

If I manually load the SoftDevice and then manually load the sketch

I’ll try changing the sketch

Edit. Just to close off this chapter…

The latest BMP code in Rick’s repo worked with my nRF51822 (32k) device !

RogerClark Sat Nov 07, 2015 9:20 pm

Rick,

2 things really

(a) BMP on Maple mini.

Any ideas on if its that invasive to change the code so that it uses the Maple hardware to reset the USB ?
(Actually I don’t know how you did it on the Blue Pill, I presume you used the GPIO USB D+ method

(b) Following on from (a)….

If we can run it on the Maple mini, I presume we can change the Vector table address and also the loader file and load the BMP via DFU into a Maple mini while still retaining the bootloader.

i.e Have this for an option for people who are not comfortable with flashing their Maple mini over to BMP using external USB to serial etc.

Either way. I think adding support for the Maple mini board would be a benefit as the Maple mini boards are physically much more robust than the Blue Pill.

Personally I don’t buy Blue Pills any more, I’d rather spend the extra couple of dollars and have a better made more reliable board.

Rick Kimball Sat Nov 07, 2015 9:23 pm

Funny I was actually thinking about spinning a maple mini …

RogerClark Sat Nov 07, 2015 9:30 pm

Rick Kimball wrote:Funny I was actually thinking about spinning a maple mini …

RogerClark Sun Nov 08, 2015 12:31 am

Rick,

One minor annoyance, which I don’t know if it occurs on the STM32

If I disconnect the BMP (connected to the NRF51) and reconnect.

The default condition seems to be that the BMP halts the nRF51. The only way to get it to run without uploading again, is to pull one of the SWD wires off.

Even if I reconnect or power cycle the nRF51 (but removing its power wire from the BMP), it still goes into halt :-(

I’ve not disconnected it and connected it to a STM32, so I don’t know if it does the same thing, but either way, I probably need to modify it, so it doesn’t default to halting the processor like this.

Rick Kimball Sun Nov 08, 2015 1:48 am

You should be able to issue the ‘run’ gdb command to restart without reloading

RogerClark Sun Nov 08, 2015 2:38 am

Yes. I could, but it still means I have to fire up gdb and connect to the board, albeit I could write a script to do it.

RogerClark Mon Nov 09, 2015 9:57 am

Update.

I think I have fixed my issue of the target board being halted on powerup.

If I change the code so that the SWD and SDIO pins are not driven low in the platform_init code e.g. change _clear to _set
like this
/* Setup GPIO ports */
gpio_set_mode(SWDIO_PORT, GPIO_MODE_OUTPUT_10_MHZ,
GPIO_CNF_OUTPUT_PUSHPULL, SWDIO_PIN);
gpio_set(SWDIO_PORT,SWDIO_PIN);

gpio_set_mode(SWCLK_PORT, GPIO_MODE_OUTPUT_10_MHZ,
GPIO_CNF_OUTPUT_PUSHPULL, SWCLK_PIN);
gpio_set(SWCLK_PORT,SWCLK_PIN);

gpio_set_mode(LED_PORT, GPIO_MODE_OUTPUT_2_MHZ,
GPIO_CNF_OUTPUT_PUSHPULL, LED_IDLE_RUN);

jcw Mon Nov 09, 2015 10:11 am

Odd – I don’t see this behaviour on my various BMP incarnations.
There’s also a “detach” command in gdb, perhaps that’s of use?
BTW, I’m using this with various non-Maple-Mini boards.

RogerClark Mon Nov 09, 2015 10:36 am

Perhaps its something specific to the nRF51 series or perhaps Cortex M0 in general.

I need to some more investigation, but I think its just one of the pins being LOW is halting the core, At the moment I just Set them both and that fixes it.

Just leaving them in their default state was no good, they definitely needed to be set High.

But I have no knowledge about how SWD works.
I presume that the programmer provides the clock signal, and the SDIO is bi directional.

I will see if I can find a simple explanation of SWD on ARM

Rick Kimball Mon Nov 09, 2015 4:02 pm

RogerClark wrote:
…
But I have no knowledge about how SWD works.
I presume that the programmer provides the clock signal, and the SDIO is bi directional.

I will see if I can find a simple explanation of SWD on ARM

Rick Kimball Mon Nov 09, 2015 4:25 pm

jcw wrote:There’s also a “detach” command in gdb, perhaps that’s of use?

Rick Kimball Mon Nov 09, 2015 4:45 pm

RogerClark wrote:I’ve posted an issue on blacksphere’s repo to ask if this is the correct thing to do, and see if anyone can advise me

Sign in to reply