As of this writing there is an stm32 microcontroller board and/or many
clones of the same board, for sale by many vendors.

Search for

STM32F103C8T6 board

Mine were $2.52 with free shipping, so I bought a handful.

Can buy them other places as well.

Got some help here, there are pictures and pinouts too.
http://cholla.mmto.org/computers/arm/stm32/
We are still working out the magic to unlock the chip the first time.
I didnt need to send the 0x92 command but when preparing to I had the
uart hooked up, maybe it was something to do with that, a pulled up or
down signal.

I didnt repeat this research myself, but my understanding is you dont
want to power via usb and the debug end of the board, one or the other.

I have various/many stm32 nucleo and discovery boards, each has an
stlink end of the board and most have jumpers you can use to disconnect
the microcontroller on the nucleo/discovery board.  So I am getting
my power and stlink from the nucleo board.  There are also standalone
stlink usb dongles for $15, but a number of the nucleo boards are $10
and the nucleo boards also can provide power and also have another
microcontroller on them to play with, so I would go with a nucleo and
then use that stlink for any other raw stm32 boards/projects.

These various stm32 boards have different versions of the stlink as
they evolved so I have simply copied the config files from openocd
here, I prefer to have a local copy, many folks dont, just my thing.

The stm32f1x.cfg sources other files, I combined all of those into
the one file target.cfg.

As pointed out in the cholla pages, the jumper next to the reset button
is boot1, the one further away is boot0.  Move boot0 to the 1 side.
In theory just needs a reset, but even better power cycle if you had
it on before moving the jumper.

openocd -f stlink_whatever.cfg -f target.cfg
Open On-Chip Debugger 0.10.0-dev-00325-g12e4a2a (2016-07-05-23:15)
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 <transport>'.
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 v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.260407
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

In another terminal

telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> halt
stm32f1x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xa1000000 pc: 0x1ffff3b8 msp: 0x200000c4
> flash write_image erase test.bin 0x08000000
auto erase enabled
device id = 0x20036410
flash size = 64kbytes
stm32f1x.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x200000c4
wrote 1024 bytes from file test.bin in 0.379937s (2.632 KiB/s)
>

I will leave a test.bin around to use.  Now here is where the trouble
begins, you might instead get a

stm32x device protected
failed erasing sectors 0 to 0

It appears you need to use the serial bootloader, boot0 jumper set to 1
then use PA9(TX)/PA10(RX) and the program in the progstm directory
or one of your own that performs a write unprotect.  Naturally it wont
work if the arm is halted as it may be if you used the above commands
so press the reset button run progstm


./progstm /dev/ttyUSB2  ../test.bin
116 bytes read
port opened
detect_chip()
chip found
get()
79 0B
22 bootloader version
00 get
01 get version and read protection status
02 get ID
11 Read Memory
21 Go
31 Write Memory
43 Erase
63 Write Protect
73 Write Unprotect
82 Readout Protect
92 Readout Unprotect
getverpstat()
0x22 version
0x00 read prot disables
0x00 read prot enables
getid()
79 01 04 10 79
write_unprotect()

And now the flash write/erase will work.

Now move boot0 back to 0, power cycle the board connect SWD again and
this time halt shows a user flash program ran


halt
stm32f1x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x41000000 pc: 0x08000046 msp: 0x20001000
>

the program counter indicates it was running a program in flash.

test.bin does this

    PUT32(0x20000800,0x12345678);

> mdw 0x20000800
0x20000800: 12345678
>

Nice!.

And can re-flash without the boot0 jumper.  The boot0 jumper is your
safety net.  If for example when you start messing with the clock
sources, you can brick the board, there are other ways your program
can cause problems. That the SWD may or may not be able to cope with.
By moving the boot0 jumper you are asking it to boot from another
bootloader on the chip, one that as far as we know, doesnt crash.

I must have been having all kinds of bad luck weeks ago.  Had I been
able to get the board to respond to progstm I might have gotten further.

./progstm /dev/ttyUSB2 ../blinker01/blinker01.thumb.bin
200 bytes read
port opened
detect_chip()
chip found
get()
79 0B
22 bootloader version
00 get
01 get version and read protection status
02 get ID
11 Read Memory
21 Go
31 Write Memory
43 Erase
63 Write Protect
73 Write Unprotect
82 Readout Protect
92 Readout Unprotect
getverpstat()
0x22 version
0x00 read prot disables
0x00 read prot enables
getid()
79 01 04 10 79
erase_flash()
erase_flash error 1
0x1F

And there you go, but if we add read_unprotect() and write_unprotect();
it seems to stop on write_unprotect().  but I have now unlocked yet
another board so dont know what the exact combination was, perhaps
it really was read_unprotect().   then if I comment those out (why
cant I just chain them?) reset/power cycle and then it works

./progstm /dev/ttyUSB2 ../blinker01/blinker01.thumb.bin
200 bytes read
port opened
detect_chip()
chip found
get()
79 0B
22 bootloader version
00 get
01 get version and read protection status
02 get ID
11 Read Memory
21 Go
31 Write Memory
43 Erase
63 Write Protect
73 Write Unprotect
82 Readout Protect
92 Readout Unprotect
getverpstat()
0x22 version
0x00 read prot disables
0x00 read prot enables
getid()
79 01 04 10 79
erase_flash()
erased
write_mem_32(0x08000000,0x20001000)
write_mem_32(0x08000004,0x08000041)
write_mem_32(0x08000008,0x08000047)
write_mem_32(0x0800000C,0x08000047)
write_mem_32(0x08000010,0x08000047)
write_mem_32(0x08000014,0x08000047)
write_mem_32(0x08000018,0x08000047)
write_mem_32(0x0800001C,0x08000047)
write_mem_32(0x08000020,0x08000047)
write_mem_32(0x08000024,0x08000047)
write_mem_32(0x08000028,0x08000047)
write_mem_32(0x0800002C,0x08000047)
write_mem_32(0x08000030,0x08000047)
write_mem_32(0x08000034,0x08000047)
write_mem_32(0x08000038,0x08000047)
write_mem_32(0x0800003C,0x08000047)
write_mem_32(0x08000040,0xF80AF000)
write_mem_32(0x08000044,0xE7FEE7FF)
write_mem_32(0x08000048,0x47708001)
write_mem_32(0x0800004C,0x47706001)
write_mem_32(0x08000050,0x47706800)
write_mem_32(0x08000054,0x46C04770)
write_mem_32(0x08000058,0x4816B570)
write_mem_32(0x0800005C,0xFFF8F7FF)
write_mem_32(0x08000060,0x43012110)
write_mem_32(0x08000064,0xF7FF4813)
write_mem_32(0x08000068,0x4813FFF1)
write_mem_32(0x0800006C,0xFFF0F7FF)
write_mem_32(0x08000070,0x4D134912)
write_mem_32(0x08000074,0x21804008)
write_mem_32(0x08000078,0x43010349)
write_mem_32(0x0800007C,0xF7FF480E)
write_mem_32(0x08000080,0x2180FFE5)
write_mem_32(0x08000084,0x0189480F)
write_mem_32(0x08000088,0xFFE0F7FF)
write_mem_32(0x0800008C,0x00202400)
write_mem_32(0x08000090,0xF7FF3401)
write_mem_32(0x08000094,0x42ACFFDF)
write_mem_32(0x08000098,0x2180D1F9)
write_mem_32(0x0800009C,0x05894809)
write_mem_32(0x080000A0,0xF
...

Then remove the boot0 jumper, doesnt appear to have to be actually in
the 0 position, just not in the 1 position (YMMV), and press reset and
then the blinker program runs.

So as cool as swd is, I may use progstm more, who knows.  Once you
get a virgin card unlocked, and so long as you dont brick things with
your application you can then use SWD to stop and reprogram without
moving the boot0 jumper.  The boot0 jumper then becomes your unbricking
option (well is in any case) and you can use SWD or the bootloader to
reprogram the application flash with something that doesnt hang.



You will want/need the datasheet and reference manual for this part
go to st.com then search for this part STM32F103C8T6 as of this
writing it gets a hit on the family STM32F103C8.  Datasheet is currently
at the top of the page and the reference manual is deeper down the
page RM0008 as of this writing.  The latter document being the
main one you use to program this part.

The board itself has port numbers next to the pins/holes.  The led
has PC13 next to it.

Start with blinker01
Once built:

> flash write_image erase blinker01/blinker01.thumb.elf

If you use the .elf file it contains address information (0x08000000)
if you use the .bin file then you need to specify 0x08000000

Press reset and the led blinks.

See the TOOLCHAIN file for info on where to find a compiler.


STM32F103C8T6

C 48 pins
8 64 Kbytes FLASH
T LQFP
6 -40 to 85C
20 Kbytes of SRAM


There are j-link devices (or clones) from asia on ebay for around $11
give or take.  Just got a couple in and they work both for traditional
full JTAG on ARM and SWD on cortex-m3.

https://www.segger.com/jlink-swd-isolator.html

You only need VTref, SWDIO, SWCLK and one of the grounds you do NOT
need SWO nor RESET.  The pinout is with respect to the connector on the
j-link not the end of the ribbon.  I didnt need an interface card or
anything else just connected to the four pins sticking off the end
of the card.   The VTref is not a power supply it is sampling the
voltage of the device to know how strong to drive the data lines (SWxxx)
3.3 or 5 or 1.8 or whatever, I dont know the full range but certainly
works with the 3.3 levels we need here.  This means you can use
the usb end of the stm32 card to plug in and power the card.

Anyway, very happy with these, it is/was getting harder and harder
to find a full ARM JTAG tool for a reasonable price (other than
an FT2232 mini module or an FT4232 mini module and a bunch of jumper
wires).

Note you either need to use -c "transport select swd" on the command
line openocd -f jlink.cfg -c "transport select swd" -f target.cfg
or as I have done here add that line to jlink.cfg

UPDATE.  Been a long while since I updated this.  First off there
are some purple j-link boards on ebay that work great.

Search for things like swd jlink without the dash in it.  or SJMCU
jlink, etc.  Currently around $6.

We can take advantage of a bootloader made for this chip/board,
you need to use one of the methods above once (uart or swd) to
program the binary file below (address 0x08000000).

Project
https://github.com/rogerclarkmelbourne/STM32duino-bootloader
binary (Select View Raw to download)
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/binaries/generic_boot20_pc13.bin

Then if you move the boot1 jumper to 1 (the jumper closest to the
reset button away from the usb connector), and press reset or power
cycle then it will go into a bootloader that supports dfu.  The PC13
led will blink.

dfu-util --list
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to [email protected]

Found DFU: [1eaf:0003] ver=0201, devnum=33, cfg=1, intf=0, alt=2, name="STM32duino bootloader v1.0  Upload to Flash 0x8002000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=33, cfg=1, intf=0, alt=1, name="STM32duino bootloader v1.0  Upload to Flash 0x8005000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=33, cfg=1, intf=0, alt=0, name="STM32duino bootloader v1.0  ERROR. Upload to RAM not supported.", serial="LLM 003"

So if we use alt=2 we can load programs at 0x08002000, so I am starting
to add a flashdfu.ld file and an additional set of binary files that
can be used

dfu-util -a 2 -D blinker01/blinker01.thumb.dfu.bin
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to [email protected]

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download    [=========================] 100%          204 bytes
Download done.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!

If you move the boot1 jumper back or remove it then press reset or
power cycle.  The dfu bootloader will start first, do some fast blinks
then it will run our program (blinker01).

Move boot1 back to 1 press reset and try again.  Allows for programming
these boards without other special tools.  Except the one time.