Dumping and reverse-engineering ST-Link v2/2-1 bootloader

[mbless]

all the clones i'v seen are st-link 2.0
and the cpu is slower and smaller than needed for 2.1

What exact micro is used on the official 2.1 if anyone knows, I'm curious, pls.

V2-1 in Nucleos use a STM32F103CBT6. See a schematic here on pg. 65. So clones with F103 are sufficient.

[Signal32]

V2-1 in Nucleos use a STM32F103CBT6. See a schematic here on pg. 65. So clones with F103 are sufficient.

Thanks! Isn't that the exact same micro that the china Stlink V2 clones have ?
Also I'm not really understanding about the V2.1 COM Port.
Which one of the following scenarios is it :

1. StLink V2.1 has 2 extra pins (Besides SWIO/SWD) which correspond to a COM port exposed to the operating system.
2. StLink V2.1 connects via SWIO/SWD (and nothing else) to the target microcontroller and then listens to a special COM port inside and exposes this separate/debug COM port inside the microcontroller to the host ?

[mbless]

V2-1 in Nucleos use a STM32F103CBT6. See a schematic here on pg. 65. So clones with F103 are sufficient.

Thanks! Isn't that the exact same micro that the china Stlink V2 clones have ?
Also I'm not really understanding about the V2.1 COM Port.
Which one of the following scenarios is it :

1. StLink V2.1 has 2 extra pins (Besides SWIO/SWD) which correspond to a COM port exposed to the operating system.
2. StLink V2.1 connects via SWIO/SWD (and nothing else) to the target microcontroller and then listens to a special COM port inside and exposes this separate/debug COM port inside the microcontroller to the host ?

Some clones have the F103. Even cheaper ones have the F101 which don't officially have USB, but it still works.

V2-1 works like scenario 1. The ST-Link breaks out SWD and UART connections. Look back at the schematic I linked. STLK_TX/RX from the ST-Link go to USART_TX/RX of the MCU.

[Signal32]

V2-1 works like scenario 1. The ST-Link breaks out SWD and UART connections. Look back at the schematic I linked. STLK_TX/RX from the ST-Link go to USART_TX/RX of the MCU.

Oh, I was expecting the other one. But, I guess, free serial link ....
Are there any other advantages to the 2.1 vs 2.0 ?

[stj]

there is if you use Linux, you dont need strange drivers.
that's probably just as usefull on windows i suppose.

also, i'm not sure if 2.0 does this, but 2.1 shows up as a usb drive and you can program the device just by dropping your bin file into it.

[mbless]

also, i'm not sure if 2.0 does this, but 2.1 shows up as a usb drive and you can program the device just by dropping your bin file into it.

No, it doesn't. The mass storage mounting is a 2-1 feature.

[dotnfc]

v2-1 is for arm mbed platform, e.g. ST's Nucleos EVA boards.
and arm mbed's debuggers should have HID+CDC+MSD interfaces ( SWD.Debug + Trace + DragnDrop )

if you know ardunio, it have a serial interface to show debug message, mbed's cdc is use for the same purpose.

[DieHertz]

Hello.
Doesn't anyone have problem with the chinese clones after FW update?
If I use V2.J27 or V2.J29 version, the programmer keep "disconnecting" from windows.
When I simply go into ST-Link Utility in Target->settings on first run I see the programmer, but after click on Refresh, it freeze for a while and then it show OLD ST-Link Firmware/ ST-Link already used.
If I downgrade to V2.J19 everything seems OK :/
I have two programmers with F101 and F102 MCU, both do it. I tried also flash the unlocked bootloader into the F101 and still the same.

BTW maybe I will have board with ST-LINK/V2-B programmer. If yes, I will dump the bootloader...

Same issue with my F303 Discovery with latest firmware, but that shouldn't be counted as a clone, right?
Btw there's a newer V2.J30 version which can be installed via a separate utility available at ST site, but it shows the same behavior. Interestingly, it only occurs when using Discovery STLink for external MCUs (NRST not connected), internal F303 never manifests this issue for me.
That was one of the reasons I've moved to BMP yesterday, I couldn't debug my F7 because STLink was losing connection to it.

[victagayun]

Hello,

I have STM32F429ZI-Discovery, the old one, which has C8 for ST-link/V2 in it while the new one, STM32F429ZI-Disc has the CB (ST-Link/V2-1) in it.
Fortunately I have the C8 with 128kb flash but havent verified it though, I can select to erase to 128kb in Flashloader Demonstrator.
How to upgrade my ST-link/V2 to ST-link/V2-1?

[legacy]

thanks for this topic, it's very useful for me 

[tsman]

How to upgrade my ST-link/V2 to ST-link/V2-1?

Flashing the V2-1 bootloader + V2-1 firmware will work but you can't use the ST-Link firmware update tool afterwards so you're stuck on that version. There is a small addition to the ST-Link circuitry on PA15 that forces a USB reenumeration which needs to be done to reenter the bootloader from the ST-Link firmware. If you don't have that extra circuit then the firmware update tool doesn't work properly on a V2-1. If only the bootloader is present and the rest of flash is empty then it waits in the bootloader for the initial firmware load.

[victagayun]

How to upgrade my ST-link/V2 to ST-link/V2-1?

Flashing the V2-1 bootloader + V2-1 firmware will work but you can't use the ST-Link firmware update tool afterwards so you're stuck on that version. There is a small addition to the ST-Link circuitry on PA15 that forces a USB reenumeration which needs to be done to reenter the bootloader from the ST-Link firmware. If you don't have that extra circuit then the firmware update tool doesn't work properly on a V2-1. If only the bootloader is present and the rest of flash is empty then it waits in the bootloader for the initial firmware load.

Hello Thank you for the reply.
I have another STM32F334-Discovery board with V2-1.
I use this instead of the V2 in STM32F429-Discovery to have VCOM port and Mass Storage which is useful for Mbed, of course I opened some SBs (shorting trace) on both boards to isolate the Master Device.
Can you be able to point to me where is the tutorial for the upgrade?
Also I am new to STM32.

[tsman]

Can you be able to point to me where is the tutorial for the upgrade?

There is no tutorial for the upgrade. I compared the V2 and V2-1 schematics on the Nucleo boards to work out why it didn't work and tested it on a metal case clone ST-LINK/V2 USB dongles. I disconnected all the SWIM pins and reused them for SWO and the virtual com port. The USB reenumeration circuit is tiny so there is plenty of space inside to add it.

If you don't mind needing to use SWD to reflash the entire ST-LINK each time you need to an upgrade then you can extract the bootloader from a V2-1 using lujji's tools. Using another ST-LINK, erase the STM32 on your victim ST-LINK/V2 and flash the bootloader. You can now plug in the victim ST-LINK/V2 and use the ST-LINK updater tool to select which V2-1 firmware you want. If you ever need to update it then you need to erase the flash and start again with just the bootloader.

If you want to use the normal ST-LINK updater tool then you'll need to add the missing transistor and a few resistors. Look at the ST-LINK/V2-1 schematic for your Nucleo board to see what is needed. It is connected to PA15.

SWO is on PA10. VCOM TX is on PA2. VCOM RX is on PA3.

[graemef]

Hi,

At the risk of the inevitable "oh great, yet another STlink programmer" comment, I decided to build on the great work and contributions of lujji, eliocor and others that reverse-engineered the STLinkV2-1 bootloader.

I have basically combined the capabilities of the STLinkV2-1 of a Nucleo board with those of the STlinkV2 ISOL.  The 60x30mm board (photo attached) includes:

STM32 SWD interface
8-pin connection to target (VCC, GND, NRST, SWCLK, SWO, SWDIO, STLINK_RX, STLINK_TX)
Designed for (but not tested/certified) Reinforced Insulation up to a working voltage of 300VAC (5kV isolation for 1min)
Supports target CPU voltages from 1.8 to 5V
Virtual COM port interface on USB
Mass storage interface on USB (Drag-and-drop Flash programming)

Once the V2-1 bootloader is installed, the programmer is recognised by the STLinkUpgrade Java package and you can load the latest firmware and set the volume name (see screenshot).

VCP and Drag-and-drop is really convenient and the isolated interface gives flexibility for different target applications.

Graeme

[robca]

Can you be able to point to me where is the tutorial for the upgrade?

There is no tutorial for the upgrade. I compared the V2 and V2-1 schematics on the Nucleo boards to work out why it didn't work and tested it on a metal case clone ST-LINK/V2 USB dongles. I disconnected all the SWIM pins and reused them for SWO and the virtual com port. The USB reenumeration circuit is tiny so there is plenty of space inside to add it.

If you don't mind needing to use SWD to reflash the entire ST-LINK each time you need to an upgrade then you can extract the bootloader from a V2-1 using lujji's tools. Using another ST-LINK, erase the STM32 on your victim ST-LINK/V2 and flash the bootloader. You can now plug in the victim ST-LINK/V2 and use the ST-LINK updater tool to select which V2-1 firmware you want. If you ever need to update it then you need to erase the flash and start again with just the bootloader.

If you want to use the normal ST-LINK updater tool then you'll need to add the missing transistor and a few resistors. Look at the ST-LINK/V2-1 schematic for your Nucleo board to see what is needed. It is connected to PA15.

SWO is on PA10. VCOM TX is on PA2. VCOM RX is on PA3.

Old thread, I know...

I tried today converting one of the ubiquitous STLink Chinese clones with a metal body into a V2-1 by flashing the 2.1 bootloader, then using the ST-LinkUpgrade.exe utility to update the rest of the firmware, and getting a "Unknown firmware type. Don't know how to upgrade", even if only the bootloader was in flash.

I then tried with an old version of the ST-LinkUpgrade.exe utility. and it worked, giving me the choice of flashing various versions of the ST Link firmware. I then tried a few different old copies, and the last ST-LinkUpgrade.exe to recognize the booloader is en.stsw-link007_V2-32-22, but that version then warns that the chip memory is not enough (because the device reports 64Kb even if there are 128Kb onboard). I found an old copy on my drive, and that reports a file version number of 2.3.24. Anything newer will stop with the error

So, somehow, in newer versions ST now checks for "fake V2-1", I assume using the lack of USB renumeration as a check. Adding the necessary 4 resistors and a transistor (on top of the 4 extra bodge wires needed for RST, SWIO, TX and RX) , is more than I bargained for. I'll just add SWIO and RST and use the Chinese clone as a 2.0, with full functionality (the clones do not allow to use semi-hosting with SWO print)

I'm attaching the relevant ST Link V2-1 USB renumeration schematic, just in case someone wants to complete the modification

[coromonadalix]

@robca   

Could you host the "old" ST-LinkUpgrade.exe  files, and send me a link in pm ?    i may need them, or  eevbloggers here too ?

thks

[robca]

EDIT 12/2/2019

After even more testing, I discovered additional issues. STLink utility works and recognizes the device, allowing to program other STM32 chips. The older Atollic Studio can use the franken-Stlinkv2-1 to debug, without problems

Unfortunately STM32CubeIDE, which is the development environment ST now supports, always checks the STLink version before starting, and a modified clone doesn't work, because it is not recognized as an STLink when checking the type (same as the STLink update utility not recognizing the device). So if you use STM32CubeIDE, you won't be able to use this hack

On the positive side, the virtual serial port works just fine (STM32+Audio firmware)

--------------------------------------------
I did a few more tests.

I have an old copy of the ST link upgrade utility from February. This is the last "fully working" version I have, and even the STM32+MSD+VCP can fit in 64k devices. You can still download en.stsw-link007_V2-32-22 from the ST website (as of yesterday) and it works, but in that version, the STM32+MSD+VCP is too big to fit, so can only flash STM32+Audio, which in any case provided a VCP port. The flash ends with a "failure exiting upgrade mode (Error 1)", which I suspect is due to the lack of a USB renumeration hardware. But simply removing and reinserting the ST link, works and recognizes the STLink plus VCP

Instead of using the EXE I tried using the jar file provided in the "AllPlatforms" directory. A jar file can be opened with any zip utility. I opened STLinkUpgrade.jar\com\st\stlinkupgrade\core\, to find all the f?_?.bin files. Replaced the files in the en.stsw-link007_V2-32-22  jar file with the same binaries from the last downloadable jar utility. Since the en.stsw-link007_V2-32-22  and the latest version use the same encryption, I now have a working ST Link 2.1 from a cheap eBay clone, with the latest firmware and VCP. Caveat: I have not soldered the necessary bodge wires to actually test the VCP, but the ST Link portion works fine, so I have no reason to think that the VCP won't

I also tried using the very old version from February and copy the latest f?_?.bin files, but I think that one and the new one have a different encryption, and did not work. The STLinkUpgrade.jar from en.stsw-link007_V2-32-22 plus latest bin files from the most recent jar file, seem to work fine

Clearly the same limitation as before apply: you need another St Link to flash the 2.1 booloader using the SWD interface of the target St Link, then use jar to update the target STLink. Once updated, the stlink upgrade utility cannot upgrade it anymore: it needs just the bootloader to be able to flash it (due to the missing USB renum circuitry)

So, if you are quick to download en.stsw-link007_V2-32-22  from the ST website before they remove it, you can update your STLink clone to 2.1 with VCP (not MSD, but personally I never found MSD to be that useful, so happy with just VCP (the weirdly named STM32+Audio)

[robca]

Update on the results of all my investigations. Mildly offtopic, I know, but this thread is the top result in most Google seraches for STLink V2-1, so I'm hoping it can help others

On a Chinese ST Link clone, after flashing the 2.1 bootloader, using en.stsw-link007_V2-32-22 to flash the STM32+Audio, I confirmed that it can then be upgraded to the latest ST Link V2-1 firmware by shorting D+ on the USB header (to +3.3V with a 100ohm resistor) just at the right moment. The USB renumerates and the STLink updater recognizes it as a 2.1. Pretty inconvenient, though

Looking thru my old STM32F103 devices, I realized that the Maple Mini (the original STM32 Arduino board) not only has an STM32F103CBT6 just like a real STLink, but also has an onboard circuit to renumerate the USB bus. The circuit has 2 transistors, different logic polarity and it's connected to a different GPIO. But with a quick trace cut, and soldering a 100ohm resistor between PB3 and the right transistor base, the circuit is identical to the one in the STLink. Then it's easy to make additional connections to make a Maple Mini into a full STLink V2-1 clone: PA5 and PB13 together are SWCLK, PB14 is SWDIO when connected to PB12 with a 220 ohm resistor, and a voltage divider between 3.3V and GND using 4.7K to 10K resistors connected to PA0. That can be updated without problems (after the initial flashing steps) with any STLink firmware, including STM32+MSD+VCP, given the 128K chip

Currently a Maple Mini sells for ~$4 with free shipping which , depending om where you live, can be significantly cheaper than a Nucleo 64 board (in the USA, it's ~$11 but unless you are ordering other stuff, you need to add $5-8 shipping). Not sure if it's worth doing all the soldering work (pretty trivial, no soldering on the STM32 pin required), definitely easier than taking a STLink clone and adding SWO and Reset lines (which requires soldering to the STM32 pins and cutting traces on the STLink clone)

I'm attaching the Maple Mini schematic with the transistor change (just that one, didn't add the other resistors to make the STLink SWD pins ready) and a picture on where to cut to use only one transistor

[RCinFLA]

Attached is the Nucleo 64 board schematic reshuffled a bit to more clearly show the interface.  Some of the Chinese Blue Pills with CWS ST32F103 clone chip have 128K Flash even when sold as 64K Flash parts.  You can check flash size by reading part with STLINK programmer application.

[DWiskow]

Based on the work detailed above, here is an easy way to create an unprotected ST-Link (V2.0 or V2.1) from an STM32F103xxxx, BluePill or Maple Mini.

Connect to the STM32F103xxxx/BluePill/Maple Mini with a USB to serial programmer and flash a bootloader (link provided below) at address 0x08000000, OR use whatever flashing device/tool(s) you prefer . . . I used an ST-Link V2 & the pystlink command.

Code: [Select]

python .\pystlink.py -c STM32F103 flash:erase flash:verify:0x08000000:Unprotected-2-1-Bootloader.bin

• Flash "Unprotected-2-0-Bootloader.bin" or "Unprotected-2-1-Bootloader.bin" at address 0x08000000 (16k bootloader) using pySTlink (after a full erase). PYSTLINK can be downloaded from here https://github.com/pavelrevak/pystlink and a copy of the bootloader(s) can be downloaded from here https://github.com/Krakenw/Stlink-Bootloaders
• Use "stlink-V2.J21.S4\ST-LinkUpgrade.exe" to load an initial [old] version of firmware (v2j21s4) onto the device. "stLink-V2.J21.S4.zip" can be downloaded from here https://drive.google.com/file/d/0Bzv7UpKpOQhnYm5Wdm1RNW1iclk/view. An overview of the various ST-Link devices and features can be obtained here https://www.st.com/resource/en/technical_note/dm00290229-overview-of-stlink-derivatives-stmicroelectronics.pdf
• Use "stsw-link007\Windows\ST-LinkUpgrade.exe" to upgrade the device to latest firmware version (v2j37s7).  Latest STM ST-Link firmware upgrade tool can be downloaded from here https://www.st.com/en/development-tools/stsw-link007.html

• choose "JTAG + SWIM" device option (i.e. ST-Link V2.0) for 64K flash devices (STM32F103C8xx) to create a simple ST-Link 2.0 device with SWD and serial wire viewer
• choose "Nucleo" device option (i.e. ST-Link V2.1) for 128K flash devices (STM32F103CBxx) to create a ST-Link 2.1 device with SWD, serial wire viewer and Virtual COM Port (VCP) on USB, PLUS Mass Storage Interface (MSD) on USB flashing

NOTES:

If you want the final ST-Link device to also be unencrypted/unprotected, it is necessary that an unencrypted version of the bootloader is flashed to the [STM32F103xxxx/BluePill/Maple Mini] device first. However, most versions of the STM ST-Link upgrade tool will not recognise the device or permit an upgrade as there will only be a bootloader on the device but no existing version of ST-Link firmware.

• The v2j21s4 version of of the STM ST-Link upgrade tool (shown above) will permit an initial version of the firmware to be loaded onto a 'blank' device that contains only a bootloader (flashed at address 0x08000000) and will flash the ST-Link firmware [over USB via the bootloader] to address 0x8004000.

Once the initial version of the firmware has been loaded onto the device, it can be readily updated to the latest ST-Link firmware over USB with the latest version of the STM ST-Link upgrade tool

• The bootloader is not updated/changed as part of the STM ST-Link firmware upgrade process, so the [STM32F103xxxx/BluePill/Maple Mini] device remains unlocked following an update and the latest version(s) of the firmware can be readily dumped and/or debugged.

A Maple Mini can be used in place of the BluePill and is preferred because of the better/correct USB implementation compared to the BluePill.

• however, with a Maple Mini a 1.5K resistor must be connected between +3.3V and D+ (PA12 / PIN23), otherwise the Maple Mini will not be recognised as a USB device. This is because the Maple Mini implementation of the USB D+ line requires that D+ is pulled up to +3.3V through a 1.5K ohm resistor, but the pull-up is turned on by a transistor switch (the transistor is controlled from PB9 which is not implemented in the ST-Link firmware)

• A stipboard layout for a Maple Mini based ST-Link V2.1 is provided below, with connector C1 providing full SWD (including SWO, RESET & 5V passthrough) and C3 providing RX/TX for the VCP

• C2 is for flashing the Maple Mini itself, using another ST-Link device

• I have also designed a PCB that a Maple Mini can be mounted directly on (PM me for more information if interested)

CONNECTIONS from STM32F103xxxx/BluePill to Target STM32 device

• Required for flashing/debugging

• PB12 must be connected to PB14 with a 100 ohm resistor

• 3.3V connects to the target STM32 (3.3v)
• GND connects to the target STM32 (GND)


• PB13 is T_JTCK and connects to the target STM32 PA14 (SWCLK)
• PB14 is T_JTMS and connects to the target STM32 PA13 (SWDIO)

• Optional


• PB0 is T_NRST and connects to the target STM32 NRST (RESET)
• PB10 is T_SWO and connects to the target STM32 PB3 (SWO trace/CMSIS-DAP)


• PA2 is UART TX and can be used to connect target UART RX to Host Computer VCP
• PA3 is UART RX and can be used to connect target UART TX to Host Computer VCP


• PA9 is ST-Link LED to visualise activity (as shown in circuit below)

[Yansi]

I just happen to have a design unfinished, where I wanted to sneak in an STLINK clone inside. Just for testing purposes, to save me some wiring on the table. Will let you know if it worked.

[crossroad]

• PB9 is ST-Link LED to visualise activity (as shown in circuit below)

Correction - LED should be PA9 instead of PB9

Was able to get this to mostly work, there's some weird bugs where some times it only work with JTAG+SWIM option

[DWiskow]

Correction - LED should be PA9 instead of PB9

Thanks, I have updated original post with correction.

The “Nucleo/SL-Link V2.1” version requires more than 64k of flash, but the “JTAG + SWIM/ST-LINK V2” need less than 64k of flash . . . I have 128K & 64k BluePills, plus 128k Maple Minis.

The “Nucleo/SL-Link V2.1” works perfectly on the 128k BluePill, but I can’t get “Nucleo/SL-Link V2.1” to connect to target when using it on A Maple Mini !

Do you have any thoughts on why it works with “ JTAG + SWIM” option, but not “Nucleo” ? . . . I originally thought this might be related to difference between USB implementation on BluePill / Maple Mini, but I am beginning to discount this line of thought now.

UPDATE: tracked down my Maple Mini issue to an incorrect resistor value between PB12 & PB14 (inadvertantly used a 220 ohm rather than the 100 ohm specified) . . . now works perfectly with VCP and MSD functionality too !

[crossroad]

UPDATE: tracked down my Maple Mini issue to an incorrect resistor value between PA12 & PA14

Surely you mean PB12 and PB14? Pin names are hard

Thanks for your work compiling the short guide

[DWiskow]

Surely you mean PB12 and PB14? Pin names are hard

Again, correct . . . I blame the dyslexia “KO”