Making a switchable ST-Link, Blackmagic and DAPLink device #2171

lbthomsen commented 2025年12月13日 13:37:47 +01:00 (Migrated from github.com)

First of all - apologies for creating this issue, which isn't really an issue with Blackmagic probe, but you guys seems to be the only ones having sorted this out.

First of all - I am using my own hardware which is to all intents and purposes an ST-Link/V2-1 (the stm32f103cb version from Nucleo). ST-Link works flawlessly and can be updated.

When I am building blackmagic firmware as described here: https://stm32world.com/wiki/Black_Magic_Probe, flash with stlink-tool from your repo, that too work flawlessly.

On this page https://github.com/blackmagic-debug/blackmagic/blob/main/src/platforms/stlink/README.md it described that after a power on it will start in st-link bootloader mode and need stlink-tool to boot the blackmagic but that is NOT what I see. After flashing blackmagic of my own build - it will start up each and every time. I can force it into bootloader mode by running stlink-tool -p and then reflash st-link firmware. In short - it works exactly as it should (but not as described in your own documentation).

Now, this is where I might lose your interest but I have build daplink firmware which can be flashed with your stlink-tool and work with st-link bootloader. That one however, works exactly like you describe in above readme - it starts up in the bootloader and need stlink-tool to run every time it is powered on.

So, in short, I know that this is daplink related and you presumably couldn't care less, but it would appear that you have figured out the "trick" at some point and I would be grateful if someone (whoever made this work) could help out with some pointers.

Please ask for any extra info you want. I really would love a device could be switched between all 3 without having to hook up an external debug probe to do so.

First of all - apologies for creating this issue, which isn't really an issue with Blackmagic probe, but you guys seems to be the only ones having sorted this out. First of all - I am using my own hardware which is to all intents and purposes an ST-Link/V2-1 (the stm32f103cb version from Nucleo). ST-Link works flawlessly and can be updated. When I am building blackmagic firmware as described here: https://stm32world.com/wiki/Black_Magic_Probe, flash with stlink-tool from your repo, that too work flawlessly. On this page https://github.com/blackmagic-debug/blackmagic/blob/main/src/platforms/stlink/README.md it described that after a power on it will start in st-link bootloader mode and need stlink-tool to boot the blackmagic but that is NOT what I see. After flashing blackmagic of my own build - it will start up each and every time. I can force it into bootloader mode by running `stlink-tool -p` and then reflash st-link firmware. In short - it works exactly as it should (but not as described in your own documentation). Now, this is where I might lose your interest but I have build daplink firmware which can be flashed with your stlink-tool and work with st-link bootloader. That one however, works exactly like you describe in above readme - it starts up in the bootloader and need stlink-tool to run every time it is powered on. So, in short, I know that this is daplink related and you presumably couldn't care less, but it would appear that you have figured out the "trick" at some point and I would be grateful if someone (whoever made this work) could help out with some pointers. Please ask for any extra info you want. I _really_ would love a device could be switched between all 3 without having to hook up an external debug probe to do so.

lbthomsen commented 2025年12月13日 13:40:11 +01:00 (Migrated from github.com)

The DAPLink behavior is described here: https://github-wiki-see.page/m/ziutek/DAPLink/wiki/DAPLink-on-STLINK

The DAPLink behavior is described here: https://github-wiki-see.page/m/ziutek/DAPLink/wiki/DAPLink-on-STLINK

dragonmux commented 2025年12月13日 14:30:07 +01:00

On this page https://github.com/blackmagic-debug/blackmagic/blob/main/src/platforms/stlink/README.md it described that after a power on it will start in st-link bootloader mode and need stlink-tool to boot the blackmagic but that is NOT what I see. After flashing blackmagic of my own build - it will start up each and every time. I can force it into bootloader mode by running stlink-tool -p and then reflash st-link firmware. In short - it works exactly as it should (but not as described in your own documentation).

This would be because that documentation reflects the behaviour of the ST-Link v2 itself, the bootloader and firmware variant found in the v2-1 on the Nucleo boards boots directly to the BMD firmware as noted. The docs aren't wrong, just a touch incomplete about that. stlink-tool still works fine though and can be used to reload other firmware if, after you've applied power, you bump nRST once on the STM32F103 - their bootloader detects this and doesn't boot the firmware but instead the bootloader when this is done after POR.

> On this page https://github.com/blackmagic-debug/blackmagic/blob/main/src/platforms/stlink/README.md it described that after a power on it will start in st-link bootloader mode and need stlink-tool to boot the blackmagic but that is NOT what I see. After flashing blackmagic of my own build - it will start up each and every time. I can force it into bootloader mode by running stlink-tool -p and then reflash st-link firmware. In short - it works exactly as it should (but not as described in your own documentation). This would be because that documentation reflects the behaviour of the ST-Link v2 itself, the bootloader and firmware variant found in the v2-1 on the Nucleo boards boots directly to the BMD firmware as noted. The docs aren't wrong, just a touch incomplete about that. `stlink-tool` still works fine though and can be used to reload other firmware if, after you've applied power, you bump nRST once on the STM32F103 - their bootloader detects this and doesn't boot the firmware but instead the bootloader when this is done after POR.

lbthomsen commented 2025年12月14日 01:25:32 +01:00 (Migrated from github.com)

This would be because that documentation reflects the behaviour of the ST-Link v2 itself, the bootloader and firmware variant found in the v2-1 on the Nucleo boards boots directly to the BMD firmware as noted.

Well, what I am trying to figure out is why, after power on, with everything else being the same, with BlackMagic firmware it boots straight into that (from st-link's standard bootloader) but with DAPLink it stays in the bootloader until stlink-tool is executed.

I would think that the st-link bootloader executes first and then decides to either stay in bootloader mode OR run the firmware on the specific address. So, the real question is, how is that decision made and I hope to find that out.

> This would be because that documentation reflects the behaviour of the ST-Link v2 itself, the bootloader and firmware variant found in the v2-1 on the Nucleo boards boots directly to the BMD firmware as noted. Well, what I am trying to figure out is why, after power on, with everything else being the same, with BlackMagic firmware it boots straight into that (from st-link's standard bootloader) but with DAPLink it stays in the bootloader until stlink-tool is executed. I would think that the st-link bootloader executes first and then decides to either stay in bootloader mode OR run the firmware on the specific address. So, the real question is, how is that decision made and I hope to find that out.

freeman1216 commented 2026年04月03日 02:19:23 +02:00

On boot ST-LinkV2 bootloader checks two things to determine if it should jump straight to the application

1. If it was reset with PoR (else jumps to DFU)
2. If the top word of ROM has the magic number 0xA50027D3 (else jumps to DFU)

This article has all the info

The check is :
Code:08002A54 BL sub_80020FC
Code:08002A58 LDR R0, =0x1FFFF7E0
Code:08002A5A LDR R1, =0xA50027D3
Code:08002A5C LDRH R0, [R0]
Code:08002A5E LSLS R0, R0, #0xA
Code:08002A60 LDR.W R0, [R0,#-4]
Code:08002A64 CMP R0, R1
Code:08002A66 BNE loc_8002A6E
Code:08002A68 BL sub_8002B70
Code:08002A6C B loc_8002A72
Which is just a fancy way to get the last word of ROM, compare it and branch

Some bmd builds probably dont touch this part of memory, however i always got boot to DFU

Options are

1. Patch the check to do something sensible (like check for a valid app reset vector)
2. Patch the firmware to include the magic word (i made a fork of stlink-tool that does just that, you can just take the code if you want)

For those wondering about daplink, it uses the last kb of flash to store perstistent settings, you need to shrink it by a kb

On boot ST-LinkV2 bootloader checks two things to determine if it should jump straight to the application 1. If it was reset with PoR (else jumps to DFU) 2. If the top word of ROM has the magic number 0xA50027D3 (else jumps to DFU) [This article has all the info](https://github.com/GMMan/st-link-hack/blob/master/paper/paper.md#main-function) The check is : Code:08002A54 BL sub_80020FC Code:08002A58 LDR R0, =0x1FFFF7E0 Code:08002A5A LDR R1, =0xA50027D3 Code:08002A5C LDRH R0, [R0] Code:08002A5E LSLS R0, R0, #0xA Code:08002A60 LDR.W R0, [R0,#-4] Code:08002A64 CMP R0, R1 Code:08002A66 BNE loc_8002A6E Code:08002A68 BL sub_8002B70 Code:08002A6C B loc_8002A72 Which is just a fancy way to get the last word of ROM, compare it and branch Some bmd builds probably dont touch this part of memory, however i always got boot to DFU Options are 1. Patch the check to do something sensible (like check for a valid app reset vector) 2. Patch the firmware to include the magic word (i made a [fork of stlink-tool](https://codeberg.org/freeman1216/stlink-tool) that does just that, you can just take the code if you want) For those wondering about daplink, it uses the last kb of flash to store perstistent settings, you need to shrink it by a kb

freeman1216 commented 2026年04月03日 02:21:11 +02:00

i can do a pr to document this if you'd like

i can do a pr to document this if you'd like

dragonmux commented 2026年04月03日 02:37:06 +02:00

Sure, a PR to document this and a PR to the project version of stlink-tool to do the patching required would be very useful - especially if coupled with a check that the firmware to be loaded has the required 4 bytes free in case a build comes out that's only a couple of bytes off entirely filling Flash.

Sure, a PR to document this and a PR to the project version of stlink-tool to do the patching required would be very useful - especially if coupled with a check that the firmware to be loaded has the required 4 bytes free in case a build comes out that's only a couple of bytes off entirely filling Flash.

freeman1216 commented 2026年04月03日 03:09:52 +02:00

@dragonmux wrote in #2171 (comment):

especially if coupled with a check that the firmware to be loaded has the required 4 bytes free in case a build comes out that's only a couple of bytes off entirely filling Flash.

Yeah i've put those safeguards, maybe a sane change is to also cut the linker script mapping by 4 bytes so that it can be checked during build

@dragonmux wrote in https://codeberg.org/blackmagic-debug/blackmagic/issues/2171#issuecomment-12588780: >especially if coupled with a check that the firmware to be loaded has the required 4 bytes free in case a build comes out that's only a couple of bytes off entirely filling Flash. Yeah i've put those safeguards, maybe a sane change is to also cut the linker script mapping by 4 bytes so that it can be checked during build

dragonmux commented 2026年04月03日 03:44:14 +02:00

Trying to safeguard that with the linker script would actually be remarkably difficult unfortunately - it's easy enough to define an area in multiple KiB, or to offset into that area for making space for bootloaders and such.. but it's remarkably difficult to trim space from the end of an area with a linker script, especially when you want all the section layout stuff generic between platforms.

Trying to safeguard that with the linker script would actually be remarkably difficult unfortunately - it's easy enough to define an area in multiple KiB, or to offset into that area for making space for bootloaders and such.. but it's remarkably difficult to trim space from the end of an area with a linker script, especially when you want all the section layout stuff generic between platforms.

freeman1216 commented 2026年04月03日 04:17:43 +02:00

Oh yeah sorry i mixed up your way of partitioning memory with Daplinks way, then simple check for size of the binary it is

Oh yeah sorry i mixed up your way of partitioning memory with Daplinks way, then simple check for size of the binary it is