Black Magic Probe on an stm32f103c8

User avatar
Rick Kimball
Posts: 1058
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Black Magic Probe on an stm32f103c8

Post by Rick Kimball » Wed Dec 07, 2016 4:43 am

* chuckles * I thought you were all hardware guys ? Normally, software types like me would be spending days looking for a software solution to fix a problem like this : )

I guess I most becoming more of a sparky. It only took me abot 15 minutes to switch a few solder bridges, load the bmp stlink platorm, and switch the solder bridges back. Now I have a very useable stm32vl discovery board running the latest bmp firmware. Now I just need to get the courage to solder some bodge wires for the uart port.

-rick
-rick

devan
Posts: 50
Joined: Sat May 14, 2016 1:45 am

Re: Black Magic Probe on an stm32f103c8

Post by devan » Wed Dec 07, 2016 5:08 am

RogerClark wrote:Have you tried changing the VID/PID on the bootloader ?

I presume you can get hold of a copy of the STLink binary that was on some russian forum. It would be easy to use a hex editor to find and change the VID /PID pair as those sorts of things are usually stored close to each other in the binary
There's no need to monkey with the VID/PID pair - you can just replace all the firmware images in the updater with the STLinkV2-1 firmware (f2_4.bin) and it has no choice but to upload the one you want. The V2-1 image still doesn't work with the V2 bootloader, though.
RogerClark wrote: BTW. Does the bootloader set the read protection on the STLink binary, or do you think the main binary protects its self (possibly both). But even if the app protected its self, the simple thing to do would be to prevent the bootloader jumping to the main STLink binary at all, so it couldn't protect its self
I think it's just the bootloader. The article discusses patching out the instruction where it rewrites the option bytes to enable read-protection before flashing the bootloader onto another board so that it won't enable read-protection.

Once it's been enabled in the option bytes, there's no way to disable it without triggering a mass-erase, though, so that isn't very helpful if the board has already turned on read-protection.
Rick Kimball wrote:* chuckles * I thought you were all hardware guys ? Normally, software types like me would be spending days looking for a software solution to fix a problem like this : )

I guess I most becoming more of a sparky. It only took me abot 15 minutes to switch a few solder bridges, load the bmp stlink platorm, and switch the solder bridges back. Now I have a very useable stm32vl discovery board running the latest bmp firmware. Now I just need to get the courage to solder some bodge wires for the uart port.
While I know that everyone here is already quite comfortable with opening up their hardware and reflashing it, I think it'd be great to have an automated process that can be rolled back in software. Unfortunately, I haven't yet found a way to pull that off.

User avatar
RogerClark
Posts: 7494
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Black Magic Probe on an stm32f103c8

Post by RogerClark » Wed Dec 07, 2016 5:24 am

@devan

I just noticed what you said about the STLink V1 not doing anything until the bootloader gets a command :-(

OK. So its probably only possible to update boards that have the mass storage version ?

devan
Posts: 50
Joined: Sat May 14, 2016 1:45 am

Re: Black Magic Probe on an stm32f103c8

Post by devan » Wed Dec 07, 2016 6:27 am

That's my understanding based on what I've seen and what the article said, but I don't know much about the STLink protocols, since I normally just immediately replace them with open-source debugger firmware.
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.
Based on what lujji wrote on the eevblog forum, the "problem" of the V2-1 bootloader running the user code every time is exactly the behavior we want, assuming we can figure out where to jump to rerun the bootloader later.

michael_l
Posts: 337
Joined: Mon Aug 24, 2015 6:11 pm

Re: Black Magic Probe on an stm32f103c8

Post by michael_l » Wed Dec 07, 2016 7:39 am

RogerClark wrote:
michael_l wrote:Well I guess it must be the hardware because I didn't flash anything to it. Maybe I accidentally put 3.3V to GND or something.

Ummm.

OK. I find the STM32 is normally quite electrically robust. The things that normally break (especially on the Blue Pill) are the USB connections from the socket to the PCB)
Yes, one possibility is that something triggered mass erase. I'll have to check the flash memory contents with another ST Link when I get some time.

I wonder if the soldering to usb is ok ?

Image
Last edited by michael_l on Wed Dec 07, 2016 3:59 pm, edited 2 times in total.

User avatar
RogerClark
Posts: 7494
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Black Magic Probe on an stm32f103c8

Post by RogerClark » Wed Dec 07, 2016 10:38 am

Guys

Just as a matter of interest, I tried following the instructions on https://lujji.github.io/blog/reverse-en ... -firmware/ and changed the binaries in the update jar file so that they were all the f2_3.bin version

This did successfully update, but I dont see any change in the Windows device manager, i.e no mass storage or USB Serial devices, so either that binary only has the stlnk device or the upgrade didnt work correctly

I tried doing the same thing with one of the larger binaries, but the firmware updater would not load it onto my STLink as it would technically not fit in flash.

Looking at that article, it seems to imply that the stlink bootloader is in the lower 0x4000 (16k) which is big for a bootloader, but it would explain how a 49k binary could not fit in a 64k device

I also looked to see if I could move the BMP start location to 0x8004000 and attempt to encrypt the binary and get the STLink updater to install it on one of my unmodified Baite STLink's, but when I changed the

Code: Select all

LDFLAGS = $(LDFLAGS_BOOT) -Wl,-Ttext=0x8002000
to

Code: Select all

LDFLAGS = $(LDFLAGS_BOOT) -Wl,-Ttext=0x8004000


in the STLink makefile.inc, the linker generates error messages, which I think mean the BMP will not fit inside the 64k boundary either, which makes sense as its 55k

So only STLink's that have the F103CB would be update-able with the BMP using ST's own updater.


Of course in reality the F103C8 has 128k, so unless the bootloader checks this, it would still be possible to update the STLink, using a different updater that didnt check for file size.

However, I don't think its worth wasting time on this, as its going to be a very small niche

michael_l
Posts: 337
Joined: Mon Aug 24, 2015 6:11 pm

Re: Black Magic Probe on an stm32f103c8

Post by michael_l » Wed Dec 07, 2016 6:08 pm

Thanks Roger, thats interesting info.

I think I've asked this before. Does BMP support printf through SWO in stm32duino? I have a project that uses serial and it would be handy to output debug prints somewhere else but still by using only BMP.

User avatar
RogerClark
Posts: 7494
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Black Magic Probe on an stm32f103c8

Post by RogerClark » Wed Dec 07, 2016 7:48 pm

Micheal

On the BMP you have to wire its serial Tx and Rx pins to the STM32 PA9 and PA10 ( USART 1)
Note. I cant recall if Tx or Rx connects to PA9, but its well documented elsewhere

michael_l
Posts: 337
Joined: Mon Aug 24, 2015 6:11 pm

Re: Black Magic Probe on an stm32f103c8

Post by michael_l » Wed Dec 07, 2016 8:33 pm

Thanks, I'll try that.

Locked