Difference between revisions of "DIY STM32 Programmer (ST-Link/V2-1)"

From Stm32World Wiki
Jump to navigation Jump to search
Line 108: Line 108:
  
 
== Revision f ==
 
== Revision f ==
 +
 +
(revision e was rejected and never produced)
  
 
<div class="res-img">
 
<div class="res-img">
 
[[File:STM32 Programmer rev. f Schematics.svg|1800px]]
 
[[File:STM32 Programmer rev. f Schematics.svg|1800px]]
 
</div>
 
</div>
 
(revision e was rejected and never produced)
 
  
 
Between rev. d and rev. e, JLCPCB changed their capabilities requiring 4 mm between cutouts and pcb edge, causing rev. e to be rejected.  Rev. f changed to 4 mm and was produced with the proper [[STM32F103|STM32F103CB]] officially having the full 128 kB of flash.
 
Between rev. d and rev. e, JLCPCB changed their capabilities requiring 4 mm between cutouts and pcb edge, causing rev. e to be rejected.  Rev. f changed to 4 mm and was produced with the proper [[STM32F103|STM32F103CB]] officially having the full 128 kB of flash.

Revision as of 09:31, 26 October 2022

Original ST-Link

ST-Link devices are almost essential when developing software for the STM32 MCUs. They are relatively cheap and easily available.

They roughly fall into two different categories. ST themselves make a number of them and they all work quite well.

One thing that annoys me with the original ST-Link devices is that the programming header is unlabelled. This essentially mean that every time I use it I have to Google for the actual pinout.

Also, the ones I've got (the one in the photo to the right) are ST-Link/V2 devices.

Before diving into any further details, credits to Martin from EmbeddedBlog who went through the same as here. His project is linked under Miscellaneous Links.

Chinese knock off ST-Link/V2

There are also a lot of Chinese clones available and while they have some limitations they also work quite well.

Unfortunately these devices are also ST-Link/V2 devices, and they do not have the SWO pin on the header, so any debug trace is impossible. For flashing and normal debugging they work fine though.

In short, the ST-Link/V2.1 devices offer a few extra features:

  1. Serial Wire Trace (SWO)
  2. Virtual serial port
  3. Mass storage

All features that, while not absolutely essential, does come quite handy.

Another reason for creating my own "programmer" is that I can experiment with using a GigaDevice GD32F103, which are much easier to source at the moment.

Original ST-Link V2.1

The schematic of the original ST-Link is readily available from the various Nucleo development modules.

ST-Link V2.1 Original Schematics.png

A bit messy schematics but it'll do.

Schematics

Based on ST's original schematics, creating a version using only parts from JLCPCB's parts library was easy (and much nicer if I shall say so myself).

DIY ST-Link V2.1.svg

One thing I left out was the serial resistors of the programming header. This might very well come back and bite me in the ass but space is going to be at a premium.

The main difference hardware wise between ST-Link/V2 and ST-Link/V2-1 is the renumeration circuitry:

ST-Link-V2-1 Renumeration Circuitry.png

I think what is going on there is ensuring the D+ is pulled high through the 1.5 kOhm resistor unless the RENUM signal is forced low. The voltage divider R4/R5 and R6 are merely there to protect the transistor itself. While I do understand what they (ST) are trying to achieve, I would say they could have achieved this much simpler. IF the D+ was simply permanently pulled high by the 1.5 kOhm resistor, since it is connected to a GPIO pin, this GPIO pin could simply be briefly yanked low at MCU reset (see STM32 USB Device Renumeration).

It should be noted that firmware update at the moment does not work and this could be related to this not being implemented correctly.

As for MCU the original ST-Link/V2-1 uses an STM32F103CB (128 kB flash). Since it is well known that STM32F103C8 MCUs also have 128 kB flash this one should do nicely too. In this case however, due to the general shortage of STM32 MCUs, I went with a GigaDevice GD32 instead. It should be "compatible" enough for this purpose.

PCB

For hobby projects like this I will usually stick with double-sided PCB. But in this particular case I wanted this to fit into the aluminium "sleeve" of the Chinese knock off ST-Link devices, so space was at a premium. Also, pricing wise there's not much difference these days, so I went for a four layer PCB and kept +3.3V and GND on the two inner layers.

For SMT assembly, JLCPCB has a minimum size of 20 mm in either direction:

JLCPCB Assembly Capabilities.png

For a USB stick 20 mm is too wide, so I had to design the PCB with a breakaway part connected with mouse bites.

The final rev. a layout looks like this:

PCB Layout rev. a.png

The KiCAD 3D model:

PCB Layout rev. a - 3D model.png

Revision a

A quick order to JLCPCB and within a week I had my first "samples".

I had to solder the USB connector by hand and it turned out that I was either out of IDC connectors (or couldn't be bothered to search long enough to dig them out of a box), so I used a simple dual-row standard 100 mil header.

DIY ST-Link w. USB connector and header.jpg DIY St-Link Hooked up.jpg

That is "good enough". For rev. b, I will put 1 mm more spacing between the IDC header and the components - that was a bit tight.

Revision d

(b and c was never produced)

This time with a proper STM32F103C8 (which isn't even proper technically).

Revision f

(revision e was rejected and never produced)

STM32 Programmer rev. f Schematics.svg

Between rev. d and rev. e, JLCPCB changed their capabilities requiring 4 mm between cutouts and pcb edge, causing rev. e to be rejected. Rev. f changed to 4 mm and was produced with the proper STM32F103CB officially having the full 128 kB of flash.

Firmware

There are a number of different options when it comes to firmware for the STM32 Programmer. While not identical, the design follows the design of the original ST-Link close enough that the original ST-Link firmware can run on it. This is however clearly troublesome from a legal and license perspective, so fortunately there are other ways.

Flashing the firmware, one will experience a bit of a chicken-egg problem. You actually need a st-link device to flash the first example.

The dodgy approach (original ST-Link firmware)

The original ST-Link firmware consists of a bootloader (presumably to add DFU capabilities to the STM32F103 which hasn't got it built-in) and an application.

Black Magic

To be added.

Issues

In revision a I used Gigadevice GD32F103CB and on that version the ST-Link upgrade utility that come with STM32CubeIde refused to upgrade the devices. Revision d was made with STM32F103C8 (the 64 kB flash version) and that version did not have enough flash to install the firmware with MSC (Mass Storage Class) support. The strangely named "STM32+Audio" version installed fine and will upgrade.

Miscellaneous Links