BlackMagic Probe, Blue Pill

Posted On February 24, 2023

Because the PSOC5LP is not readily available for the Weekend Engineer (no CY8CKit-059 boards available now), I have had to look elsewhere. The EOS S3 has caught my attention, but it is in the early stages, and I am not certain how much effort QuickLogic will put into it. I want an ARM Debug session for working with it. That requires a debugger, which the QuickFeather does not seem to supply.

I have a J-Link, but I know you probably will not. The J-Link edu is out of stock world wide, and discontinued from many vendors. The J-Link probes are $500 to $2000 in cost, so are out of the weekend engineering price range. So I have been looking.

During my work towards finding a cheap ARM Cortex debugger for use with VSCode and the QuickFeather (QuickLogic) board, I stumbled across a possible hardware solution. And a Software/Firmware solution.

Black Magic Firmware

There is an open source debugging probe called BlackMagic Probe. You can google or bing to purchase that probe in hardware form, but it is currently out of stock. It will run you about $25 to $30. The $16 Flikr board from Amazon may not be a good deal, read the reviews before purchasing.

The github.io page for the BlackMagic probe software/firmware is here: https://github.com/blackmagic-debug/blackmagic.

The Black Magic probe runs a serial port version of GDB on the probe itself. To connect to it, you tell your GDB Debugger to use an extended-remote connection over a serial port. I consider that a stroke of genius, and it cuts *way down* on driver incompatibilities.

Blue Pill

I stumbled across the Blue Pill board. There is a board with a STM32F103 on it. It is called the “Blue Pill” in the Weekend Engineering community.

This board can be programmed via a serial port if you have some soldering skills and a USB to TTL serial port adapter, such as a KitProg3. (Pins 12-6 and 12-7 on the KitProg3 debug stub are the RS232 i/o lines. See previous posts for more information on use of the serial port.)

It has a USART (Universal Synchronous/Asynchronous Receiver/Transmitter) DFU boot loader which can be connected to through the plated through vias on the side of the board. You need to be able to solder.

A Blue Pill will run you, from Amazon, about $25 for two boards. You can also get an STLink V2 clone and a blue pill board combo. I have read that the connector pins sometimes have oxidized on these cheap clones, so you may have to plug/unplug to wipe the connectors clean and get good connections.

You will need to upload the BlackMagic code to the Blue Pill board. The web page telling you how to do this is here: https://paramaggarwal.medium.com/converting-an-stm32f103-board-to-a-black-magic-probe-c013cf2cc38c

If you have an STLink V2 probe or a clone, you may be able to program the Blue Pill following the instructions here: https://jeelabs.org/202x/bmp/. That last page has a lot of useful information for use on the Macintosh (and probably Linux).

STLink Clone To BlackMagic Probe

Please see a newer post for programming and using BlackMagic Probe with VSCode from a clone STLink, here: https://socmaker.com/?p=1491

STLink V2.1 to Segger

Using Segger utilities, you can modify a legal STLink V2.1 to a Segger J-Link OB, which has about the same capabilities as J-Link Base. You can also put it back. The license only allows you to use that particular Segger-OB on ST processors. I don’t know if that is enforced in firmware, but if you have a Nucleo board sitting around with a detachable STLink on it, you might find you can cheaply debug using VSCode a lot of different processors.

VSCode can debug using the STLink V2.1 probe. The YouTube page for debugging with the STLink is here: https://www.youtube.com/watch?v=g2Kf6RbdrIs. It will give you a lot of good insights on setting up for both J-Link and STLink.

Easter Egg Hunt

The information in this post is out there, but takes a lot of digging to uncover. Kudos to Segger for providing an upgrade path for STLink to J-Link OB for use with ARM processor families. Their debug code is the best in the industry. And the most expensive.

The ARM processor is taking the embedded world by storm. I am fairly certain all the other processor families will die quiet deaths. I find it amusing that the Motorola 68000 processor is the closest processor architecture to the ARM processor. I found it a gem to program (in assembly) when it came out. It just made so much logical sense. Too bad Motorola succumbed early to the culture that is trying to destroy us today. But I digress.

So far, most of the newer debug boards from Renesas, Infineon, STMicro, etc. have inexpensive versions that allow for debugging, and many use Segger-OB for that. For most of these, there are hacks and allowances for allowing VSCode to be used across all their on board debuggers. This allows you, as the Weekend Engineer to get a leg up on your fellow engineers by tinkering on the weekend. This kind of work on your part can save your job. It certainly saved mine several times in the past.

VSCodium

I was surprised to find that VSCode sends *a lot* of information back to Microsoft. It is called Telemetry. Fortunately, you can turn it off, but it is defaulted to *all* information being sent back to Microsoft, probably even keystrokes. They can, if they wish, steal your code. On the Mac, go to Code -> Preferences -> Telemetry to turn off. It is probably in a similar place on the Windows and Linux version.

VSCodium is supposed to fix this. Since VSCode base is under MIT, the VSCodium folks take that base and try to make it mainly VSCode compatible. Microsoft takes that base and adds the telemetry and other things you may like or dislike. The VSCodium site is here: https://VSCodium.com. I have not yet tried it.

Fini

I hope this brain dump helps the Weekend Engineering community.

Enjoy!