If you don't have a Bus Pirate, this is the inexpensive path to being able to talk to the SWD port on an STM32 series ARM controller.
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.
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 IM DIO GND GND 3.3 3.3 5.0 5.0The supplied cable has 4 wires (nicely matching the 4 pins on the SWD connector on my STM32F103 board). That SWD connector is labelled: GND, CLK, IO, 3.3. 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.
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.
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 6We 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:
openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f1x.cfgI 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 selectThen I launch a telnet connection to this, press the reset on my target unit, and type "reset halt".
'. 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
Open On-Chip Debugger > reset halt target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x1ffff020 msp: 0x200001fcWell, 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.
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 (but the extra may have bad pages or who knows). But ignoring 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)
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 003So 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.
Tom's Computer Info / firstname.lastname@example.org