March 8, 2025

STM32F429 Discovery Kit - try an external ST-link

As reported in the prior pages, my board is now rejecting attempts to download code into it.

A couple of days after deciding to box it up and set it aside, I got an idea. Why not try one of my cheap stlink dongles that I uses with F103 and F411 boards? The f429 board has jumpers to easily disconnect the onboard ST-link (and connect an external one).

Power. We have a number of choices. What I decided to do is to let the cable to the on-board st-link supply power for this exercise. We know that will reliably run both the onboard F103 and the F429.

Ground. The board has two jumpers, one in each corner, at the end near the ST-Link usb connector. These are labeled "GND" and it turns out that both pins in each are connected to ground. There is a jumper on each on the back of the board, which seems entirely pointless.

This leaves us with SWCLK and SWDIO. We can tap into these using the CN4 jumpers. The top is pin 1. Pin 1 and 3 come from the F103. So we want pin 2 and 4. Pin 2 is SWCLK, Pin 4 is SWDIO.

My dongle has 4 wires dangling from it. We will ignore one of these (that has 3 volts). On my unit, the colors dictate the following: 

Orange - 3 volts -- ignore
Green - Ground -- to one of those GND pins in the corners
Yellow - SWCLK - to pin 2 on CN4
Blue - SWDIO - to pin 4 on CN4
The ground pins are longer on the back side of the board, so I connect to one of those.

Some hacking required

Now the first significant issue presents itself. I have two ST-Link devices plugged into my linux machine given this arrangement. The onboard is 

Mar  8 15:29:31 trona kernel: usb 4-1.5: New USB device found, idVendor=0483, idProduct=374b, bcdDevice= 1.00
Mar  8 15:29:31 trona kernel: usb 4-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar  8 15:29:31 trona kernel: usb 4-1.5: Product: STM32 STLink
Mar  8 15:29:31 trona kernel: usb 4-1.5: Manufacturer: STMicroelectronics
Mar  8 15:29:31 trona kernel: usb 4-1.5: SerialNumber: 066BFF545052836687101947
The external cheap clone is: 
Mar  8 15:29:45 trona kernel: usb 2-1.1: New USB device found, idVendor=0483, idProduct=3748, bcdDevice= 1.00
Mar  8 15:29:45 trona kernel: usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar  8 15:29:45 trona kernel: usb 2-1.1: Product: STM32 STLink
Mar  8 15:29:45 trona kernel: usb 2-1.1: Manufacturer: STMicroelectronics
Mar  8 15:29:45 trona kernel: usb 2-1.1: SerialNumber: Wÿp#006PuUQ"E!
The product ID is different, so we should be able to make things work. I just try my download script to see if I get lucky (I don't). I see 
Info : STLINK V2J36M26 (API v2) VID:PID 0483:374B
The interface script I am using is /usr/share/openocd/scripts/interface/stlink.cfg Looking at it gives me several ideas. There are some notes about using the serial number (but cautions me that V2 devices have serial numbers with unreadable characters). Better yet though is a line with a list of vid/pid values.

I copy stlink.cfg to sthack.cfg and edit this line to have only the 0483/3748 value. Then I am able to download one of my demos! 

make flash
openocd -f /usr/share/openocd/scripts/interface/sthack.cfg -f /usr/share/openocd/scripts/target/stm32f4x.cfg -c "program serial.elf verify reset exit"
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 2000 kHz
Info : STLINK V2J21S4 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.248180
Warn : target stm32f4x.cpu examination failed
Info : starting gdb server for stm32f4x.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : [stm32f4x.cpu] Cortex-M4 r0p1 processor detected
Info : [stm32f4x.cpu] target has 6 breakpoints, 4 watchpoints
[stm32f4x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000150 msp: 0x20020000
** Programming Started **
Info : device id = 0x20036419
Info : flash size = 2048 KiB
Info : Dual Bank 2048 kiB STM32F42x/43x/469/479 found
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked
The question now is whether it will now be possible to use the on-board ST-Link for further work. It takes only seconds to remove the external ST-Link and put the board into the original state I try downloading my "serial1" bare metal demo -- and it works! It even works multiple times.

Now I try downloading the latest build of Hydra (which is what caused the original trouble). That works. And it works a second time.

So this little game has been a complete success.

I have NO idea what caused the problem to start with. Because of this, I fully expect this to happen again, but at least now I know what I can do to get going again.

The next day -- here we are again!

The board was unplugged, sitting on my desk all night. I want to get back to work and it is again "bricked" in the same way.

If I am going to need to do this daily, I'll have to add an "unbrick" entry to my Hydra makefile. I do so.

Indeed, this works once again and away I go.

Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org