stm32f4_BMP.md

(This guide is based on my following this other guide: https://embdev.net/articles/STM_Discovery_as_Black_Magic_Probe)

If you have a BMP or some other device with the BMP firmware already, flashing the ST-Link processor (the F103) on a Discovery board is straightforward. But if all you have is one Discovery board - like me - it's possible, but has to be done in a roundabout way.

Discovery boards are really two different parts. Right next to CN1 - the mini-USB connector - is the ST-Link section, which is powered by a small STM32F103 MCU. It has its own bootloader and firmware, separate from the device under test. This ST-Link section is normally responsible for loading, running, and debugging programs on the device under test (DUT).

The DUT is the larger STM part in the middle of the board. I have an STM32F4 Discovery board which has an F407 as the "test" MCU. What we're going to take advantage of is a feature called the DFU bootloader which will allow us to bypass the ST-Link section and instead directly load firmware onto the DUT through the second USB port.

We're going to flash BMP onto the ST-Link in three steps:

1. Flash BMP onto the DUT, turning the DUT into a BMP temporarily
2. Use the DUT to flash the BMP DFU bootloader onto the ST-Link processor
3. Flash BMP onto the ST-Link processor directly now that we have our own bootloader

Step 0: Modifying the hardware

This is already described! I wasn't sure I had to do this but yep, you do. Clear SB3, SB5, SB7, SB9 and connect SB2, SB4, SB6, SB8. You don't really need to reuse the links, the bridges are narrow enough that a big blob of solder is enough.

I also bridged the left side of SB3 to SB5 and the left side of SB7 to SB9 since I want to use the BMP to debug the DUT on this board (I have nothing else to use it on right now...).

Step 1: Flashing the BMP firmware onto the DUT

It's good to have a real-ass development environment like Linux set up for this. I used Linux in a VirtualBox VM which worked... alright. There were some USB issues which I'm not sure were my fault or VBox's fault.

1. Clone https://github.com/blacksphere/blackmagic.
2. cd into that directory and do:

make PROBE_HOST=f4discovery

Once it finishes, it will create blackmagic and blackmagic.bin in the src/ directory.

3. Jumper together the BOOT0 pin to the VDD pin, and the PB2 pin to the GND pin. These pins are immediately next to each other in the middle of the large connectors on each side. Conveniently, ST includes some jumpers attached to the ground pins on the underside of the board!

Now power the board through CN1 (mini-USB), but connect the board to your computer through CN5 (micro-USB). It should show up as something like "STMicroelectronics Bootloader".

4. Use DFU to upload blackmagic.bin to 0x08000000. Note: Make sure that no Option Bytes are protecting the flash. (I confirmed this with the ST-Link utility on Windows.)

dfu-util -v -d 1d50:6017 -a 0 -s 0x08000000:leave -D src/blackmagic.bin

For some reason, this failed the first several times. I thought I had something set up incorrectly. Then, randomly, it worked fine. I have no idea why. VM USB weirdness?

5. Remove the jumpers from the BOOT0 and PB2 pins.
6. Reset the DUT with button B2 "Reset". The orange LED should come on steady with CN5 disconnected, and dim with CN5 connected and the device enumerated.

If this happens, you did it! The DUT is now a BMP.

Step 2: Flashing the BMP DFU bootloader onto the ST-Link processor

The "ST-LINK/DISCOVERY" jumper on the board marked CN3 is actually the STM32F103's debug port. The hardware modifications done earlier will now let us connect and debug it externally - from the DUT.

Note: if, like me, you didn't do the hardware modifications first, the next few steps will seem to work until the mon swdp_scan command, which will not quite list the same thing, and the att 1 command will sit and do nothing and never connect. Make sure you modified the hardware!

Pin 1 is the one with a round dot next to it on the silkscreen. It's closest to the CN1 edge of the board. Pin 4 is the opposite end.

1. Connect pin PC4 to CN3 pin 4.
2. Connect pin PC5 to CN3 pin 2.
3. Power the board through CN1 and connect the board to your computer through CN5. The orange LED should go dim.

At this point you should have a blackmagic CDCACM modem in e.g. /dev/ttyACM0. Make sure you have it first.

4. Recompile Blackmagic for the ST-Link target:

make clean
make PROBE_HOST=stlink

This should create blackmagic_dfu and blackmagic_dfu.bin in the src/ directory.

5. Start the ARM debugger (I used arm-none-eabi-gdb) with src/blackmagic_dfu and run these commands, like so:

$ arm-none-eabi-gdb src/blackmagic_dfu

(gdb) tar ext /dev/ttyACM0
Remote debugging using /dev/ttyACM0
(gdb) mon swdp_scan
" Target voltage: ABSENT!
Available Targets:
No. Att Driver
1      STM32, Medium density."
(gdb) att 1
...
(gdb) mon option erase
...
(gdb) load
...
(gdb) quit</pre>

Note: if you get Error erasing flash with vFlashErase packet on the load command, likely you cleared the option bytes but they have not taken effect yet. You must power-cycle the ST-Link processor before they take effect. This was very confusing for me!

Step 3: Flashing BMP onto the ST-Link processor

At this point the DUT has done its job and can be disconnected from the ST-Link processor (the jumper wires to CN3) and from the USB (CN5).

1. Connect CN1 (the ST-Link processor) to your computer. The ST-Link blackmagic bootloader device should appear with VID/PID 1d50:6018.

On Windows, this device appeared but was marked as an "Unknown Device" and was unusable. I had to use the Zadig utility to connect to the Unknown Device and install the libusbK driver.

2. Use DFU to upload blackmagic.bin compiled for STLink to 0x08002000:

dfu-util -a0 -d 1d50:6018,:6017 -s 0x08002000:leave -D blackmagic.bin

On Windows, I was able to run this command using the Windows dfu-util binary, as I still wasn't able to attach the device to my VM even with the libusbK driver. Again, not sure if it was just my VM being weird, but that's what I had to do.

Yayyyyy!