ST Link V2

September 5, 2020

This is by far the smartest and best path to being able to talk to the SWD port on an STM32 series ARM controller.

A quick note up front. You can flash "black magic probe" software into your ST-Link and make it into a Gdb gateway. An interesting concept to consider:

I keep reading about the ST Link in posts about using the STM series ARM controllers. For some reason I assumed this was some expensive gadget I would never be able to justify shelling out the money for. It turns out you can buy the genuine article from DigiKey or Newark for $24 or so. Better yet (maybe) you can buy a clone from China for $4 or so. I ordered one off of Ebay that ships out of Los Angeles (free shipping) for $4.99. For an extra dollar or so I can avoid the 30 day wait for a unit to come from China.

This is a little dongle like thing with a USB connection on one end, and a header that accepts a bunch of probes (or small ribbon cable) at the other end.

st-link software

This comes along 2 years after I first started working with these. A piece of software just to deal with these little gadget:

It arrived!

On September 22 -- only 2 days from California. A good seller. The unit has a black outer shell that is actually metal (they come in many colors). The shell slips off so you can admire what is inside, which is an STM32F101CBT6 along with an 8 Mhz crystal and other components, including a pair of LED's labelled "r" and "b". The hole in the case is centered between the two, so you may get a two color effect.

There are 10 pins as follows (viewing the unit end on with the key to the left). Note that not all units have the same pinout!! This is how mine is, but online photos I have seen show different pinouts. Take care. 

RST  CLK
SWIM IO
GND  GND
3.3  3.3
5.0  5.0
Not so fast though -- I pull a second one out of its bag and it has a different pinout! 
RST  IO
GND  GND
SWIM CLK
3.3  3.3
5.0  5.0

The supplied cable has 4 wires, which is perfect since I have 4 pins to connect to on the SWD connector on my STM32F103 board). The 3.3 should only be connected if the STLINK is powering the board. If the board is plugged into USB, then connecting 3.3 from both ends could cause trouble. That SWD connector on the STM32F103 board is labeled: 

GND
CLK
IO
3.3

I plug it into my linux system (Fedora 24 x86_64) and see in the log messages: 

Sep 22 20:30:29 trona kernel: usb 1-1.3: new full-speed USB device number 29 using ehci-pci
Sep 22 20:30:29 trona kernel: usb 1-1.3: New USB device found, idVendor=0483, idProduct=3748
Sep 22 20:30:29 trona kernel: usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Sep 22 20:30:29 trona kernel: usb 1-1.3: Product: STM32 STLink
Sep 22 20:30:29 trona kernel: usb 1-1.3: Manufacturer: STMicroelectronics
Sep 22 20:30:29 trona kernel: usb 1-1.3: SerialNumber: Wÿp#006PuUQ"E!
So I connect it up to my STM32F103 development board.

Unlocking the STM32

Before diving into the following, I want to note that as received, my boards seem to be locked against reading or writing. I did the following experiments using openOCD on a board I had previously unlocked through the serial bootloader (by sending the 0x92 "disable readout protection" using a C program I wrote). This command erases flash, but then unlocks the board (or so it seems). Trying to do the "dump_image" commands in the procedure followoing on a "factory" board, results in all of the commands being silently ignored and rejected. Attempting to flash to the board results in the following: 
flash write_image erase maple_mini_boot20.bin 0x08000000
auto erase enabled
device id = 0x20036410
STM32 flash size failed, probe inaccurate - assuming 128k flash
flash size = 128kbytes
stm32x device protected
failed erasing sectors 0 to 6
We are getting ahead of ourselves here, but it is only fair to warn you that the smooth sailing described below requires an unlocking trick before it will work. If you want my serial unlocking program, you can get it here: The following forum post talks about some weird hanky-panky using GDB to unlock an STM32:

Run openOCD

I am going to run openocd from the Fedora packages, installed via "dnf install openocd". 
openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f1x.cfg
I crammed all of the above into a script named "ocd" so I don't have to remember all of that (or type it). When I run "ocd", I see: 
Open On-Chip Debugger 0.9.0 (2016-05-13-19:37)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v21 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.252485
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Then I launch a telnet connection to this (using "telnet localhost 4444"), press the reset on my target unit (for no particular reason), and type "reset halt". 
Open On-Chip Debugger
> reset halt
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x1ffff020 msp: 0x200001fc
Well, this looks good. I am running with the BOOT0 jumper set to run the bootloader. Also due to some other previous fiddling around, I believe flash should be cleared.

Read some stuff

We can check and see if flash has been cleared: 
dump_image dump.bin 0x08000000 0x20000
dumped 131072 bytes in 2.586631s (49.485 KiB/s)
Note that the above dumps 128K of flash, but my unit should only have 64K. We will see about that. I have heard rumors that these units actually have more than the "official" 64K. I learned years later that these chips are not genuine ST parts, but are clones made in China, and in general do have 128K of good usable flash. My fear was that the other 64K might have bad pages or some flaw, but it would seem not. On the other hand I have yet to write software bigger than even 32K, so who knows. Ignoring all that for now, the dump indeed looks like all bytes of 0xff.

While we are at it, lets do this: 

dump_image bootloader.bin 0x1ffff000 0x800
dumped 2048 bytes in 0.038240s (52.301 KiB/s)
Attempting to dump 4K at this address simply failed with no messages. This file looks like the real thing. We can dump SRAM and the option bytes also: 
dump_image sram.bin 0x20000000 0x5000
dumped 20480 bytes in 0.383217s (52.190 KiB/s)
dump_image options.bin 0x1ffff800 0x200
dumped 512 bytes in 0.010241s (48.823 KiB/s)

Write something to flash

Now the question arises, can we write anything? In particular, can we write anything to flash? I fetch a candidate binary from the following link (the whole project is worth taking a look at). I download the file maple_mini_boot20.bin, which is 7036 bytes. Then I load it to flash via: 
flash write_image erase maple_mini_boot20.bin 0x08000000
auto erase enabled
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000003a msp: 0x200001fc
wrote 7168 bytes from file maple_mini_boot20.bin in 0.433384s (16.152 KiB/s)
This is virtually instantaneous (making me suspicious), but apparently it actually worked! Don't ask me why it reports 7168 bytes when the linux file size is 7036 bytes. Actually I do know. It is rounding up to even multiples of 256 (7168 = 28*256) -- the flash "sector" size is 256 bytes and it has to write entire sectors to the flash.

After this, I disconnect the ST-Link power and plug the STM32F103 in using a USB cable directly. Watching /var/log/messages on my linux box I see: 

Sep 22 21:15:10 trona kernel: usb 3-2.1: new full-speed USB device number 10 using xhci_hcd
Sep 22 21:15:10 trona kernel: usb 3-2.1: New USB device found, idVendor=1eaf, idProduct=0003
Sep 22 21:15:10 trona kernel: usb 3-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Sep 22 21:15:10 trona kernel: usb 3-2.1: Product: Maple 003
Sep 22 21:15:10 trona kernel: usb 3-2.1: Manufacturer: LeafLabs
Sep 22 21:15:10 trona kernel: usb 3-2.1: SerialNumber: LLM 003
So this is good! It indicates that I really did flash something with complete success. Note that the Maple boot loader is now quite tiny (about 8K) about half what it was in October, 2015 when Clark Melbourne did his work. Also note that there are other bootloaders I might want to investigate (along with investigating what gadget I need to talk to these boot loaders).

There were rumors about a resistor that needed to be changed on some boards like mine before they would work with USB, but mine seems fine so far. This needs further study. Maybe the folks in China learned about the wrong resistor and fixed everything.

Resources and Links

The following fellow looks to be working with the same exact generic board I am, but his ST-Link is different. It is labelled as a genuine item, but he says it is a clone. His general approach led me along my way.
Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org