EEVblog Electronics Community Forum

Electronics => Microcontrollers => Topic started by: lujji on October 16, 2016, 02:17:18 pm

Title: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: 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/ (https://lujji.github.io/blog/reverse-engineering-stlink-firmware/)
Part2: 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:
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 (https://github.com/lujji/st-decrypt).
Dumper firmware: st-link-dumper (https://github.com/lujji/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:
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 (https://www.eevblog.com/forum/profile/?u=3095) for providing useful insights and advice!
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 firmware
Post by: dannyf 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.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 firmware
Post by: lujji 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.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 firmware
Post by: bingo600 on October 16, 2016, 03:31:08 pm
Btw:

The  F103C8 i have , do have 128k flash  ;)

/Bingo
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 firmware
Post by: lujji on October 16, 2016, 03:39:54 pm
Not as cool as my F101 having a USB :D
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.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 firmware
Post by: dannyf on October 16, 2016, 03:47:24 pm
Quote
Not as cool as my F101 having a USB :D

Check the ghetto thread here. it is not just limited to STM32 chips.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 firmware
Post by: bingo600 on October 16, 2016, 04:33:50 pm
Quote
Not as cool as my F101 having a USB :D

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

URL ?

/Bingo
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 firmware
Post by: Sal Ammoniac on October 17, 2016, 04:31:15 pm
Quote
Not as cool as my F101 having a USB :D

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 (http://lmgtfy.com/?q=ghetto+site%3Ahttp%3A%2F%2Fwww.eevblog.com%2Fforum%2Fmicrocontrollers%2F)
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: lujji 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.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 firmware
Post by: eliocor on October 17, 2016, 10:23:25 pm
Quote
Quote from: dannyf on Yesterday at 16:02:45 (https://www.eevblog.com/forum/index.php?topic=75894.msg1049246#msg1049246)>
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?
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: devan 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:


With these changes, you should be able to load your custom debugger firmware and roll it back without any JTAG/SWD access.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: Krakenwak 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.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: lujji 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"
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: ass20 on April 23, 2017, 07:48:58 am
hi
 can i dump fw from another stm32 devices with this dumper?
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: dotnfc 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.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: Yansi on January 13, 2018, 01:44:09 pm
All the documentation and software is available on github.
Part1: https://lujji.github.io/blog/reverse-engineering-stlink-firmware/ (https://lujji.github.io/blog/reverse-engineering-stlink-firmware/)
Part2: 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 (https://github.com/lujji/st-decrypt).
Dumper firmware: st-link-dumper (https://github.com/lujji/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 (https://www.eevblog.com/forum/profile/?u=3095) 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.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: cdev 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
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: lujji on January 16, 2018, 05:11:11 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.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: 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...
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: 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
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: Benik3 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...
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: Signal32 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 ?
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: stj on January 19, 2018, 01:54:34 pm
from the pc side?
it i.d.'s as a usb>serial adapter
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: dotnfc 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.  :D
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: Signal32 on January 19, 2018, 04:12:26 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 ?

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.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: mbless on January 19, 2018, 04:57:42 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 (http://www.st.com/content/ccc/resource/technical/document/user_manual/98/2e/fa/4b/e0/82/43/b7/DM00105823.pdf/files/DM00105823.pdf/jcr:content/translations/en.DM00105823.pdf). So clones with F103 are sufficient.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: Signal32 on January 19, 2018, 08:48:35 pm
V2-1 in Nucleos use a STM32F103CBT6. See a schematic here on pg. 65 (http://www.st.com/content/ccc/resource/technical/document/user_manual/98/2e/fa/4b/e0/82/43/b7/DM00105823.pdf/files/DM00105823.pdf/jcr:content/translations/en.DM00105823.pdf). 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 ?
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: mbless on January 19, 2018, 09:26:13 pm
V2-1 in Nucleos use a STM32F103CBT6. See a schematic here on pg. 65 (http://www.st.com/content/ccc/resource/technical/document/user_manual/98/2e/fa/4b/e0/82/43/b7/DM00105823.pdf/files/DM00105823.pdf/jcr:content/translations/en.DM00105823.pdf). 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.

Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: Signal32 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 ?
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: stj 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.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: mbless on January 20, 2018, 02:12:20 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.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: dotnfc 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.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: DieHertz on February 22, 2018, 10:11:01 am
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.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: victagayun 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?
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: legacy on October 30, 2018, 09:48:48 pm
thanks for this topic, it's very useful for me  :D
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: tsman on October 30, 2018, 11:53:06 pm
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.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: victagayun on October 31, 2018, 07:19:05 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.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: tsman on October 31, 2018, 04:01:55 pm
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.
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: graemef 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
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: robca on November 29, 2019, 12:40:09 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
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: coromonadalix 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
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: robca 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)
Title: Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
Post by: robca 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