Author Topic: Dumping and reverse-engineering ST-Link v2/2-1 bootloader (Read 47192 times)

lujji · « **on:** October 16, 2016, 02:17:18 pm »

All the documentation and software is available on github.
Part1: https://lujji.github.io/blog/reverse-engineering-stlink-firmware/
Part2: https://lujji.github.io/blog/reverse-engineering-stlink-firmware-part2/

This is what we can do so far:

decrypt and encrypt firmware images from the updater utility
upload and execute any code on the programmer
dump the bootloader of ST-Link v2 or v2-1
clone ST-Link onto an empty micro
disable protection (allows debugging)

The official StLinkUpgrade utility contains the firmware binaries. You can use it to flash your own encrypted images as well.
Encrypting/decrypting firmware binaries: st-decrypt.
Dumper firmware: st-link-dumper.

So what do you think? Any ideas on what we can do with it? There are a few things I'm interested in:

~~being able to convert any st-link into st-link + VCP~~
adapt a generic open-source bootloader to support st-link firmware
reverse-engineer the protocol and come up with an st-link compatible programmer?

Given the fact that we can now use a debugger, last option seems doable.

P.S.: I can't share binary dumps for obvious reasons. But if you own an ST dev-board, you can easily obtain one yourself.

Big thanks to eliocor for providing useful insights and advice!

dannyf · « **Reply #1 on:** October 16, 2016, 03:02:45 pm »

Quote

So what do you think?

it was done over a year or so ago.

there is also a jlink v10 source code, binary + schematic available.

lujji · « **Reply #2 on:** October 16, 2016, 03:17:02 pm »

Not exactly. I think you're referring to the article that covered extracting the firmware from the updater utility. The firmware itself is of little value without the bootloader. I also haven't seen any replicas of ST-Link v2-1 (mbed and VCP) so far.

bingo600 · « **Reply #3 on:** October 16, 2016, 03:31:08 pm »

Btw:

The F103C8 i have , do have 128k flash

/Bingo

lujji · « **Reply #4 on:** October 16, 2016, 03:39:54 pm »

Not as cool as my F101 having a USB

By the way, have you checked that all the pages can be written without errors? We should come up with some memtest utility to check how much 'spare' flash MCU has.

dannyf · « **Reply #5 on:** October 16, 2016, 03:47:24 pm »

Quote

Not as cool as my F101 having a USB

Check the ghetto thread here. it is not just limited to STM32 chips.

bingo600 · « **Reply #6 on:** October 16, 2016, 04:33:50 pm »

Quote from: dannyf on October 16, 2016, 03:47:24 pm

Quote
Not as cool as my F101 having a USB

Check the ghetto thread here. it is not just limited to STM32 chips.

URL ?

/Bingo

Sal Ammoniac · « **Reply #7 on:** October 17, 2016, 04:31:15 pm »

Quote from: bingo600 on October 16, 2016, 04:33:50 pm

Quote from: dannyf on October 16, 2016, 03:47:24 pm
Quote
Not as cool as my F101 having a USB

Check the ghetto thread here. it is not just limited to STM32 chips.

URL ?

/Bingo

http://lmgtfy.com/?q=ghetto+site%3Ahttp%3A%2F%2Fwww.eevblog.com%2Fforum%2Fmicrocontrollers%2F

lujji · « **Reply #8 on:** October 17, 2016, 04:41:59 pm »

I finished part 2 of the writeup - link in the first post.. I also changed 'firmware' to 'bootloader' in the title to be fair (since I haven't done much about the actual firmware).
A proof-of-concept dumper firmware is on github (https://github.com/lujji/st-link-dumper). Most convenient solution would be to use USB instead of UART, but I just didn't have time for that. For some reason ST-Link 2-1 refused to enter DFU mode after I flashed it and just kept booting into the user-code, so make sure that you have another programmer to flash back the original bootloader once you dumped it. No such problem on ST-Link v2. Use at your own risk.

And yes, I can confirm that by flashing 2-1 bootloader on an stm32f103c8 and updating it to "STM32+Audio" I was able to get st-link with UART support.
Have fun.

eliocor · « **Reply #9 on:** October 17, 2016, 10:23:25 pm »

Quote

Quote from: dannyf on Yesterday at 16:02:45>
there is also a jlink v10 source code, binary + schematic available.

Hi, dannyf
will you be so kind to give me some references about what are you referring to?
I tried to make some searches, but with no avail.
Even from Segger documentation, last HW release of J-Link is 9.2
Any link?

devan · « **Reply #10 on:** December 14, 2016, 05:20:57 am »

If anyone's interested I've worked out what changes are necessary to port whatever (open-source) debugger firmware you want to work with the STLink/v2-1 bootloader:

The vector table has to be relocated manually to 0x08004000 - the bootloader doesn't change it for you
The bootloader also leaves the USB and TIM1 interrupts enabled - you may need to disable them
To return to DFU mode, trigger a software reset - the bootloader will check the RCC CSR flag and run in DFU mode

With these changes, you should be able to load your custom debugger firmware and roll it back without any JTAG/SWD access.

Krakenwak · « **Reply #11 on:** December 24, 2016, 01:58:40 pm »

Superb work, I wish I could have thought of it.

For those who like me, who are nervous about extracting the bootloader,
I've put some useful files here: https://github.com/Krakenw/ST-Link-Bootloaders
which can be used with many of the STM32F1 series that you have lying around like
the ebay maple & Minimum System Development Module.

lujji · « **Reply #12 on:** February 16, 2017, 08:21:50 pm »

I ported Black Magic Probe firmware to native bootloader (because why not?).
The idea is that you can install BMP without destroying the bootloader, so that you can revert to the original firmware if needed.

Links:
1. write-up: https://lujji.github.io/blog/installing-blackmagic-via-stlink-bootloader/
2. firmware source: https://github.com/lujji/blackmagic/tree/stlink-bootloader
3. updater utility: I'm not sure I can upload it.. but someone did, so here's a link https://mega.nz/#!cNV0wIAY!LNNj7xzZtjN3xP8R1LSStnhrumnam_hGSrnPlPEOvRo.
If someone objects I'll edit the message and remove it.

You'll need to create udev rule under linux, texane/stlink is needed:

Code: [Select]

# /etc/udev/rules.d/99-stlink.rules
ACTION=="add", SUBSYSTEM=="usb", \
               ATTR{idVendor}=="0483", ATTR{idProduct}=="3748", \
               MODE="0666", RUN+="/usr/local/texane/st-info --probe"

ass20 · « **Reply #13 on:** April 23, 2017, 07:48:58 am »

hi
can i dump fw from another stm32 devices with this dumper?

dotnfc · « **Reply #14 on:** January 13, 2018, 12:23:11 pm »

hi, here is my thought for step further: using stlink-btl to boot stlink-app and cmsis daplink.

this is the bootup flow:

Code: [Select]

               +-->    DFU Mode    <-------------------------------+
    STLink-BTL |             +-->  PB6 is low  (force DFU mode)  --+
               +--> PrjCode  |-->  STLink-APP
                             +-->  DAPLink-APP (VolumeName ==  'DAPLink')
we can use  'java -jar STLinkUpgrade.jar -volume "DAPLINK    " -force-prog' to change VolumeName

here is the memory map:

Code: [Select]

    +------------------------------+ 0x0800 0000
    |      STLink-BTL cracked      |
    +------------------------------+ 0x0800 3400
    |      this project code       |
    +------------------------------+ 0x0800 3C00
    |        STLink-APP CFG        |
    +------------------------------+ 0x0800 4000
    |          STLink-APP          |
    +------------------------------+ 0x0801 3000
    |      DAPLink Admin CFG       |
    +------------------------------+ 0x0801 3400
    |          DAPLink-APP         |
    +------------------------------+ 0x0801 FC00
    |      DAPLink User CFG        |
    +------------------------------+ 0x0802 0000

and, How to upgrade APP FW:

Code: [Select]

    -  STLink-APP: stsw-link007.zip (ST-LinkUpgrade.exe or STLinkUpgrade.jar)
    - DAPLink-APP: STLinkUpgrade.jar modified f2_4.bin ( 'STLink-APP' + 'DAPLink Admin CFG' + 'DAPLink-APP')

By doing so, we can hold STLink/DAPLink on one singe STM32F103C8/B chip, and choose one of them on the fly.

Yansi · « **Reply #15 on:** January 13, 2018, 01:44:09 pm »

Quote from: lujji on October 16, 2016, 02:17:18 pm

All the documentation and software is available on github.
Part1: https://lujji.github.io/blog/reverse-engineering-stlink-firmware/
Part2: https://lujji.github.io/blog/reverse-engineering-stlink-firmware-part2/

This is what we can do so far:
decrypt and encrypt firmware images from the updater utility
upload and execute any code on the programmer
dump the bootloader of ST-Link v2 or v2-1
clone ST-Link onto an empty micro
disable protection (allows debugging)
The official StLinkUpgrade utility contains the firmware binaries. You can use it to flash your own encrypted images as well.
Encrypting/decrypting firmware binaries: st-decrypt.
Dumper firmware: st-link-dumper.

So what do you think? Any ideas on what we can do with it? There are a few things I'm interested in:
~~being able to convert any st-link into st-link + VCP~~
adapt a generic open-source bootloader to support st-link firmware
reverse-engineer the protocol and come up with an st-link compatible programmer?
Given the fact that we can now use a debugger, last option seems doable.

P.S.: I can't share binary dumps for obvious reasons. But if you own an ST dev-board, you can easily obtain one yourself.

Big thanks to eliocor for providing useful insights and advice!

Just a simple question: The purpose fo all this is... ?

You better invest your time in telling those damned Chinese manufacturers to include an SWO pin on their damned cloned STLINKs.

You better invest your time into making OpenOCD at least half usable as a tool.

Thanks. We already have cheap enough programmers/debuggers already. There is no point in working on that.

cdev · « **Reply #16 on:** January 13, 2018, 02:59:46 pm »

Those little ST-link v2 clone dongles in their colorful metal cases make nice little micros for small projects.

For example, this looks like my next project for one.

https://github.com/danielkucera/st-link-dht11

lujji · « **Reply #17 on:** January 16, 2018, 05:11:11 pm »

Quote from: Yansi on January 13, 2018, 01:44:09 pm

Just a simple question: The purpose fo all this is... ?

You better invest your time in telling those damned Chinese manufacturers to include an SWO pin on their damned cloned STLINKs.

You better invest your time into making OpenOCD at least half usable as a tool.

Thanks. We already have cheap enough programmers/debuggers already. There is no point in working on that.

It's entirely up to me to decide where I invest my time.

Benik3 · « **Reply #18 on:** January 17, 2018, 10:23:58 pm »

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...

stj · « **Reply #19 on:** January 18, 2018, 05:37:12 pm »

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

Benik3 · « **Reply #20 on:** January 18, 2018, 08:01:16 pm »

Yes, st-link v2.1 need MCU with 128kb flash. I don't know if the higher performance is also needed.
I'm still not able to get working the chinese clones with newer firmware :/
Today I tried flash another bootloader+firmware from one russian forum, which (what I get from translator) should be original from ST-Link programmer.
No change, the bootloaders looks same, there is only small difference at 0x000021B0, which is the protection...

Signal32 · « **Reply #21 on:** January 18, 2018, 10:33:00 pm »

Excellent work ! Havent looked extensively into this, but , in code, how do you output to the stlink UART ?

stj · « **Reply #22 on:** January 19, 2018, 01:54:34 pm »

from the pc side?
it i.d.'s as a usb>serial adapter

dotnfc · « **Reply #23 on:** January 19, 2018, 02:48:26 pm »

ST should open stlink2-1 for mbed platform, or porting daplink to STM32 chip(s) officially. NXP did well than ST on this.

Signal32 · « **Reply #24 on:** January 19, 2018, 04:12:26 pm »

Quote from: stj on January 19, 2018, 01:54:34 pm

from the pc side?
it i.d.'s as a usb>serial adapter

No, from the Firmware/micro side.
On the host PC it does identify as a COM port indeed. Question was how do I output data from the micro so that it would reach this com port ?

Quote from: stj on January 18, 2018, 05:37:12 pm

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.

mbless · « **Reply #25 on:** January 19, 2018, 04:57:42 pm »

Quote from: Signal32 on January 19, 2018, 04:12:26 pm

Quote from: stj on January 18, 2018, 05:37:12 pm
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 · « **Reply #26 on:** January 19, 2018, 08:48:35 pm »

Quote from: mbless on January 19, 2018, 04:57:42 pm

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 · « **Reply #27 on:** January 19, 2018, 09:26:13 pm »

Quote from: Signal32 on January 19, 2018, 08:48:35 pm

Quote from: mbless on January 19, 2018, 04:57:42 pm
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 · « **Reply #28 on:** January 19, 2018, 11:06:16 pm »

Quote from: mbless link=topic=75894.msg1404825#msg1404825

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 · « **Reply #29 on:** January 20, 2018, 12:20:04 am »

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 · « **Reply #30 on:** January 20, 2018, 02:12:20 am »

Quote from: stj on January 20, 2018, 12:20:04 am

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 · « **Reply #31 on:** January 20, 2018, 01:48:28 pm »

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 · « **Reply #32 on:** February 22, 2018, 10:11:01 am »

Quote from: Benik3 on January 17, 2018, 10:23:58 pm

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 · « **Reply #33 on:** October 30, 2018, 10:25:13 am »

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 · « **Reply #34 on:** October 30, 2018, 09:48:48 pm »

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

tsman · « **Reply #35 on:** October 30, 2018, 11:53:06 pm »

Quote from: victagayun on October 30, 2018, 10:25:13 am

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 · « **Reply #36 on:** October 31, 2018, 07:19:05 am »

Quote from: tsman on October 30, 2018, 11:53:06 pm

Quote from: victagayun on October 30, 2018, 10:25:13 am
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 · « **Reply #37 on:** October 31, 2018, 04:01:55 pm »

Quote from: victagayun on October 31, 2018, 07:19:05 am

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 · « **Reply #38 on:** November 26, 2018, 03:00:44 am »

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 · « **Reply #39 on:** November 29, 2019, 12:40:09 am »

Quote from: tsman on October 31, 2018, 04:01:55 pm

Quote from: victagayun on October 31, 2018, 07:19:05 am
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 · « **Reply #40 on:** November 29, 2019, 02:20:55 am »

@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 · « **Reply #41 on:** November 29, 2019, 07:03:50 pm »

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 · « **Reply #42 on:** December 07, 2019, 12:11:48 am »

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 · « **Reply #43 on:** April 08, 2020, 01:09:25 pm »

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 · « **Reply #44 on:** March 23, 2021, 11:09:05 am »

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 · « **Reply #45 on:** March 23, 2021, 11:24:14 am »

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 · « **Reply #46 on:** March 25, 2021, 08:49:25 am »

Quote from: DWiskow on March 23, 2021, 11:09:05 am

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 · « **Reply #47 on:** March 25, 2021, 09:32:13 am »

Quote from: crossroad on March 25, 2021, 08:49:25 am

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 · « **Reply #48 on:** March 26, 2021, 02:49:39 am »

Quote from: DWiskow on March 25, 2021, 09:32:13 am

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 · « **Reply #49 on:** March 26, 2021, 08:44:30 am »

Quote from: crossroad on March 26, 2021, 02:49:39 am

Surely you mean PB12 and PB14? Pin names are hard

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

DWiskow · « **Reply #50 on:** April 24, 2021, 12:09:04 am »

Would anybody be interested in a PCB that can turn an STM32 Maple Mini (readily available for under $5 from China) into an unencrypted ST-Link V2.1?

This exploits the processes explained in this thread (and my post above with links to the necessary files) to load an unencrypted bootloader onto the Maple Mini and then flash/update it with the latest ST-Link V2.1 firmware

The resulting ‘ST-Link 2.1’ equivalent device will have SWD flash and debug functionality, plus serial wire viewer and Virtual COM Port (VCP) over USB, AND Mass Storage Interface (MSD) for simple ‘copy file to virtual USB drive’ flashing

DavidAlfa · « **Reply #51 on:** April 24, 2021, 04:51:26 am »

Why? When you can do that with the $3 stlink mini

DWiskow · « **Reply #52 on:** April 25, 2021, 10:00:15 pm »

Quote from: DavidAlfa on April 24, 2021, 04:51:26 am

Why? When you can do that with the $3 stlink mini

A few reasons

the resulting ST-LinkV2.1 incorporates a Virtual Com Port enabling UART input/output between computer and the target device (and also supports drag & drop programming of the target over virtual USB drive on windows/mac/linux)
an exercise in learning KiCAD for schematic/PCB design
I happen to have a few Maple Mini boards going spare, so $3.70 (unit price per PCB delivered in qty of 3 from OSHpark) to turn one into a ST-Link V2.1 seems quite reasonable
It is significantly less fiddly than cutting tracks and having to solder directly to the pins of an STM32F103 LQFP-48 package on a Chinese clone of an ST-Link V2
Not all Chinese clone ST-Link V2 incorporate the 128k flash STM32F103CBT6 required to flash the latest release of the V2.1 ST-Link firmware
All of the connections to the target device are properly labeled
I wanted to have an “unencrypted/unprotected” ST-Link that I could disassemble/debug over its own SWD interface

Finally, I though others who already had an STM32F103CB based Maple Mini could benefit from sharing the PCB (easily and inexpensively purchased and shipped worldwide from OSHpark). The PCB(s) can be obtained here https://oshpark.com/shared_projects/mtkoCb6c $11.30 for 3 (including shipping).

robca · « **Reply #53 on:** April 25, 2021, 11:40:36 pm »

Nice job, @DWiskow

Just to provide more options, I recently bought an STLINK-V3MINI (roughly $10 from Mouser/Digikey). Got a 14 pin header at the same time (one of these, depending where you order from https://www.mouser.com/_/?Keyword=20021311-00014T4LF&bws=1 https://www.digikey.com/en/products/detail/20021311-00014T4LF/609-3756-ND/2209089) and a $2.25 PCB adapter I designed from OSHPark. Actually the $2.35 are for 3 adapters

(shared here https://oshpark.com/shared_projects/zOLm9ezB). The STDC14 cable is not a standard yet and pretty hard to find adapters at the moment. That's why I hacked together an adapter that uses standard 2.54 headers

The header I got is not keyed, but it's easy enough to insert it correctly (the "USB ->" points towards the USB). For around $15 you can get a much better STLink 3, with VCP, drag and drop and much faster than the older devices. Also guaranteed to work in the future

Definitely the hacked solution are cheaper, but the STLink V3Mini is not much more and a really nice/small device

DWiskow · « **Reply #54 on:** April 26, 2021, 08:00:17 am »

@robca, I created an almost identical board for the ST-Link V3mini I have . . . I found that you can ‘key’ the female connector by supergluing a small piece of black plastic to the connector

[I do this with the 10 pin connector on ST-Link V2 Chinese clones too]

peter-h · « **Reply #55 on:** May 01, 2021, 07:18:21 am »

May I ask a stupid question:

Why does anybody bother reverse engineering the STLINK when you can buy the latest 24MHz one (V3) for about 30 quid?

robca · « **Reply #56 on:** May 01, 2021, 04:58:08 pm »

Quote from: peter-h on May 01, 2021, 07:18:21 am

May I ask a stupid question:

Why does anybody bother reverse engineering the STLINK when you can buy the latest 24MHz one (V3) for about 30 quid?

For a variety of reasons:

To learn by using something a person already has (Blue Pill, Maple or a clone)
Because a V2 clone can be flashed into a J-Link, much more powerful than even the STLink V3
Because the price of a STLink V3 depends on where you live, and in some places price+shipping is 10x the cost of a clone
Because for most debugging purposes, especially on a low end processor (STMF1-F4), the speed of the debugging probe is irrelevant
Because until recently, the V3 was not available, and a V2 clone was by far the best way to get started
Because, apart from the VCP (which you can anyway simulate using a separate FTDI USB Serial), the V3 doesn't offer anything more than a V2

A V3Mini is even cheaper, but once again only recently became available. These days I would probably recommend a V3 over any V2 clone

For someone developing professionally, clearly the hacked V2 clone was never a good option. But for a hobbyist that was not sure about STM32 development, the V2 clone and a Blue Pill was the cheapest way to get into STM32 coding, for around $5 all included


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Dumping and reverse-engineering ST-Link v2/2-1 bootloader (Read 47192 times)

Share me