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

Replies20

mrburnette Tue Oct 20, 2015 8:30 pm

zmemw16 wrote:nice trick
<…>
i’m using the using-spi-ports example with my additions, heading towards a driving nokia 5110 (my success with adafruit_gfx_as is really, really non stella)
<…>

RogerClark Sun Oct 25, 2015 7:10 am

Rick,

I tried to Flash you BMP binary onto a GD32, but it didnt work.

But now that I think about it….. Its impossibe for it to work because the Xtal is 12Mhz instead of 8Mhz, so all the PLL’s will be wrong for it to enumerate on USB. (The USB prescaler PLL also has 2 bits instead of 1 bit on the STM32)

If I get time, I”ll download all the sources and see if it will Make on my Windows PC (As I make the stm32duino bootloader using my Windows PC, so I should have an equivalent setup)

In the mean time I’ve flashed it onto a STM32 to I can take a look at if it can see the RNF51822

Thanks

Roger

RogerClark Sun Oct 25, 2015 10:21 am

Rick,

This is probably a really dumb question,but here goes.

If cloned your repo then ran git submodule update to get the libopencm3, however it won’t make because the code can’t find the stm32 directory in libopencm3

I just went into src and then ran make, but possibly because I’m trying to do this on Windows, it seems to have something missing from the path, as it is looking in libopencm3/stm32/…. but the actual structure appears to be libopencm3/lib/stm32/…

Do I need to Make libopencm3 ? (Its not that easy for me to do that as I’d need to sort out the Python stuff on my machine)

Or is there something else I’ve missed?

Rick Kimball Sun Oct 25, 2015 11:16 am

run the make from the top level directory. it will do the git submodule stufffor you

RogerClark Sun Oct 25, 2015 8:07 pm

Rick,

Thanks.

I’m not sure why I didnt see the top level makefile after I cloned your repo.

I perhaps I was just having a bad day.

RogerClark Sun Oct 25, 2015 11:09 pm

Update

OK. I figured out why I didnt run the top level make file… It was because it was using Python, which I didnt have setup for command line usage.

So I’d manually run the git submodule update stuff, but when I ran make on both libopencm3 and the src folder, I’d not included the correct make options as specified in the top level make file.

Anyway. I can now make the code, but the resulting bin doesnt work on my RedPill, but your binary does.

You bin file is 49k but mine is 65k :-(

I’m using the ARM compiler installed by the Arduino IDE, I just set the Windows PATH ENV to include it.

I’m on the jc66_coreboard branch, and I”m running make from the top level and don’t get any errors.

I guess the first thing I should try and do is recompile on Linux. Can you let me know your setup for gcc on Linux, as although I could use the one from the Arduino IDE, I’d rather use whatever you used, in case this is some sort of library issue

Thanks

Roger

Rick Kimball Mon Oct 26, 2015 1:35 pm

I have the linaro arm-none-eab-gcc binary for linux version 4.8.4 in my path:

$ arm-none-eabi-gcc --version

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.4 20140725 (release) [ARM/embedded-4_8-branch revision 213147]

RogerClark Mon Oct 26, 2015 5:12 pm

Rick

Thanks.

I will try setting the probe host.

I didnt do that before, as it looked like you had created a branch in your repo which defaulted to those files.

But its possible it still effects the build process.

I will let you know how i get on

thanks

roger

Rick Kimball Mon Oct 26, 2015 6:56 pm

yes I originally had changed the PROBE_HOST value in the Makefile in my branch. However, it takes less effort on my part to use their Makefile if I want to easily get in synch with the master branch. Sorry.

RogerClark Mon Oct 26, 2015 9:58 pm

Success

Thanks

make PROBE_HOST=jc66_coreboard all

RogerClark Mon Oct 26, 2015 11:06 pm

Rick,

FYI.
I just posted about Arduino on the nRF51822 , being available

viewtopic.php?f=45&t=682

However I’m not sure if its reliant on Red Bear hardware

jcw Wed Oct 28, 2015 6:40 pm

If it’t not too much to ask: what is the status of BMP on generic ST32F103[CR][8B]’s?
I’ve been going through this thread, but am having some difficulty distilling the answer to that question.

RogerClark Wed Oct 28, 2015 7:18 pm

jcw wrote:If it’t not too much to ask: what is the status of BMP on generic ST32F103[CR][8B]’s?
I’ve been going through this thread, but am having some difficulty distilling the answer to that question.

Rick Kimball Wed Oct 28, 2015 7:26 pm

RogerClark Wed Oct 28, 2015 7:33 pm

Just a note.

The C8 generic board shown in the posting in the first link is junk. (aka the Ugly board)

I find it unreliable and have given up using it.

I know some people get it to work, but personally i would not recommend it.

jcw Wed Oct 28, 2015 7:56 pm

Thanks, R & R.

@Roger – I’m not sure why that “Ugly Board” is being so, eh, ugly to you. I had one lying around and re-flashing Rick’s build onto it seems to work – well, at least it shows up on USB (on Mac). I did have to change the jumpers: outermost one is towards the corner, but the inner one is away from the board edge.

Now I’m wondering whether PA8/PA9 serial can also be used.

Update – confirmed, this unit seems to work.
Update #2 – serial pass-through also works, on PA2/PA3, as documented.

RogerClark Wed Oct 28, 2015 8:02 pm

Perhaps mine has a component fault.

I know some of them work, but a lot seem to fail to start.

Actually I think the issue is that the HSE clock (external crystal clock ) fails to start first time.

The libmaple core doesn’t include any checks to see if the HSE has started, it just hangs while waiting.

I suspect the BMP code handles this correctly and retries starting then HSE, which then works Ok.

The HSE timeout and restart is on the bottom of a long ToDo list for me ;-)

RogerClark Thu Nov 05, 2015 11:11 am

I’ve tried to use the BMP to flash a Nordic nRF51822, and gdb seems to accept all the commands, but it doesnt seem to actually write the sketch to flash.

I’ve adapted Ricks platform.txt gdb commands and removed the STM specific memory reads, and have also manually typed and executed the commands, but with no luck so far.

On Windows I have 2 other issues.
1. The COM port seems to need to be preceded by \\.\ , as described I think in BMPs own wiki
2. On the nrf51, the quit command is not getting executed by gdb, so gdb ends up
locking up the BMP, and the only way to release is to reboot the pc, or to remove the target power or one of the SWD lines.

I will need to see if I have the same issues with quitting when targeting the stm32.

However I’ve no idea why the nrf51 is not getting flashed by the load command.
The bmp is supposed to support the nrf51 series.

BTW. mass erase is not available in the gdb commands for the nrf51, although mass erase is available on the mcu, ( as openocd does it via the. nrf51 mass_erase. command

I dont think the flash is being erased at all, as after Its supposedly flashed and running, I still see the debug messages from the exiting ( different ) sketch. :-(

jcw Thu Nov 05, 2015 11:18 am

The \\.\ stuff is due to COM port numbers above 9 (or 4?), I think. Gdb (cygwin?) doesn’t recognise “COM<n>” as a special name (which is a horrible Windows anachronism, if you ask me – try creating a file named “COM3” …).

Indeed, I’d try this on an F1 first. Perhaps you have to update your BMP to get the latest chip support.

Never a dull moment, eh? 🙂

Rick Kimball Thu Nov 05, 2015 1:51 pm

jcw wrote:Indeed, I’d try this on an F1 first.