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 Mon Nov 09, 2015 8:37 pm

Hi Rick

No worries about the j66_coreboard.

I did wonder where it came from, as i noticed it wasn’t in the Master repo as far as i could tell.

Perhaps for the GD32 and maple mini, I should copy your j66 folder and make changes, rather than trying to put #ifdef s in the j66 platform

Rick Kimball Mon Nov 09, 2015 8:45 pm

That would be cleaner.

Or even fork off the upstream.

RogerClark Mon Nov 09, 2015 8:58 pm

Rick Kimball wrote:That would be cleaner.

Or even fork off the upstream.

Rick Kimball Mon Nov 09, 2015 9:04 pm

RogerClark wrote:Rick Kimball wrote:That would be cleaner.

Or even fork off the upstream.

RogerClark Mon Nov 09, 2015 9:13 pm

LOL

Ok..

:lol:

RogerClark Mon Nov 09, 2015 10:04 pm

Rick,

Why did you “clear” both SWD pins in the init () ??

I took a look at the stlink files and they don’t seem to clear those bits.

Actually they don’t clear them either, so I suspect the default state is LOW, but I’d need to double check.

Set’ing those bits seems to fix things for me, so I think I’ll leave it like that

But I’ll clone off blacksphere’s repo, then add you j66 coreboard as GD32F103_120Mhz – with my changes, and also make Maple mini version and a generic stm32f103c version (very similar to your j66)

I’ll credit you in the comments.

I also want to add a binaries folder to the repo. I’m not sure if this is politically correct for github, but a lot of projects have hex files etc for download in the repo.

Rick Kimball Mon Nov 09, 2015 10:54 pm

RogerClark wrote:Why did you “clear” both SWD pins in the init () ??

RogerClark Mon Nov 09, 2015 10:59 pm

Clearing seems to do the same thing as doing nothing

If I remove them the nRF51 still seems to go into halt on power up.

I actively need to set them

I’m not sure what the default input state is on the SWD pins on the nRF51, if they are not connected, I suspect that both pins just float.
However I’m not sure if they float high or just float.

I suspect they must have some sort of pull up of pull down on them, otherwise the SWClock will get noise pickup and it may think its being clocked with random data, which sounds like a recipe for unreliable start-up’s

Rick Kimball Mon Nov 09, 2015 11:09 pm

Yeah at the beginning of the thread is a conversation about how you don’t need pullup/pulldowns for the stm32f chips .. And originally that is all I cared about. You might try to find a similar document from Nordic, explaining about the default state of the JTAG/SWD pins

RogerClark Mon Nov 09, 2015 11:21 pm

Thanks, I’ll see if I can find the equivalent Nordic doc

Edit.

https://devzone.nordicsemi.com/question … resistors/

Strange.

They seem to say that both pins are OK in a default state of being pulled down. However, If the BMP “clears” both, the module goes into debug mode.

From the posting on Nordic’s site there seems to be some differences between which revision of the chip is being used, but they all seem to need to default to being LOW; either with internal or external.

But its strange if I do this using the BMP there seems to be a problem with this.

I’ll need to try just pulling those lines low using resistors and see if it has the same effect, as I wonder if its caused because the platform init() is being caused some time after powerup.
I’ll probably need to stick my scope / logic analyser on it.

jcw Thu Nov 12, 2015 2:01 pm

Aha, great trick, Rick – thanks!

RogerClark Thu Nov 12, 2015 9:20 pm

Sorry.

I posted a follow up to the other Offtopic nRF thread.

It appears that SWDIO on the nRf51 doubles up as the Reset pin.
Rick. If you look on your nRf motherboard, the button marked Reset appears to connects / shorts SWDIO to Gnd when you press it.

I’m still waiting for my motherboard ;-(

jbforrer Fri Nov 13, 2015 6:43 am

Greetings,

Great work on the diy BMP! That is a handy tool.
I’ve had good luck using a Blue Pill and the pre-complied binary: downloading sketches works fine, also gdb works as described.
The only hardware modification was replacing the 10k (R10) pullup with 1.5K.

Was wondering what additional features are in the latest git sources?
I managed to build a new BMP bin file after fixing paths to the ARM toolchain resulting 65,604 byte binary.
The pre-compiled binary was 50,096 bytes.

Does that sound reasonable?

Thanks for all the efforts.

RogerClark Fri Nov 13, 2015 7:11 am

Rick has made some changes to support the nRF51 device (Nordic Bluetooth Low Energy), but I don’t think that would account for the difference in file size, as its only a minor change.

If you binary is over 64k (which I think it now is), then technically it won’t fit in a stm32f103c8 however in reality most of the chips labelled as stm32103C8 are actually the stm32f103CB i.e the larger flash version.
So I think you should be OK even if it is that size

I’d just give it a try and if its no good, reflash back to the precompiled version ;-)

jcw Sat Nov 14, 2015 9:39 am

FWIW, I’ve posted an article about the Black Magic Probe here http://jeelabs.org/book/1546d/
With thanks to @rick for creating and sharing his BMP build.

RogerClark Sat Nov 14, 2015 8:11 pm

I just thought I’d let you know that I modified the source code a tiny bit and the BMP works fine on the Maple mini (no surprises here)

The changes are very minor, you just change the USB reset stuff to use a different pin, and swap the Set and Clear calls around the other way, and you don’t need the delay loop.

I will put the new ‘platform’ in my clone of blacksphere’s repo, but I need to push just the NRF51 changes first as I want to do a PR back to blacksphere’s repo just for the nRF51 stuff.

I was hoping to do a version of the BMP which I could relocate to run from 0x8005000 so it couldnt be installed on a Maple mini via the bootloader, but the base address in libopencm3 doesnt seem easy to change, as it appears to be defined in lots of places, and I didnt want a custom version of libopencm3 in my BMP repo.

jcw Sat Nov 14, 2015 8:24 pm

Congrats on getting BMP into an MM.

RogerClark wrote:[…] the base address in libopencm3 doesnt seem easy to change, as it appears to be defined in lots of places

RogerClark Sat Nov 14, 2015 8:31 pm

JeanClaude

Interesting link…

I will need to check the libopncm3 code on my machine

I searched the current github repo version and I cant find 0x800000 in the source, but I am fairly sure its in the version I am using for the BMP ( but I will need to double check)

Umm hang in, i will find what version it us and search github ;-)

Edit.

I meed so search in my codebase as i cant see in it blackspheres version either.
ummm. very strange.. I may be talking rubbish.

Edit

OK.

I was not going totally mad.

The base address for STM32 is defined inside libopencm3 (at least the version that the Blacksphere’s repo uses)

See this search

https://github.com/libopencm3/libopencm … x08000000U

So… It could be changed, but, you’d need to change stuff inside libopencm3

I’ve just check again, and even the most recent version of openlibcm3 has this hard coded into the stm32f1 device

So as far as I can tell, you’re going to need to fork openlibcm3 and modify it, then you’ll need to detach the libopencm3 submodule from your code (if you have attached a submodule) and attach your fork of openlibcm3 which has the base address changed in a few places.

RogerClark Sun Nov 22, 2015 5:13 am

Any tips on how to tell on a Mac, which device is the the GDB server

(actually its a shame that the name is not displayed on either windows or OSX)

Sign in to reply