Sometimes Things Go Wrong and you find you have a dev board in a state where you can't do anything with flash, which is now mysteriously filled with Really Weird Shit. Today's procedure covers the very recent unwedging of an STM32F051-Discovery board. Don't ask us how it happened, this board showed up in this state.
You have to sidechannel via the serial bootloader
Normal jtagging via muforth/stlink is not going to work. You have to use the serial bootloader. In the example below, we're using a PL2303, but this will work with an FTDI-2232H etc. You just need something that will do serial that has TX, RX, GND and 3.3V.
1) Put female-female jumper wires on the following pins of the PL2303: RXD, TXD, GND, 3.3V
2) Jumper BOOT0 and VDD on the F051 board with a wire or one of those nifty jumper pins pirated off one of your other boards.
3) Attach the PL2303 to the F051 board as follows:
4) When you build muforth on Linux, it automagically decides muforth/mu/serial-target should symlink to /dev/ttyS0. This needs
to change because it's a nervy assumption. In this case, the PL2303 will enumerate as /dev/ttyUSB0. Let's get things set up.
One more "gotcha" --- not all systems have the same idea about which device belongs to which group. Archlinux, for example, decided that this /dev/ttyUSB0 belonged to group uucp, so if you're not a member, you need to add yourself to that group, logout and log back in.
$ sudo usermod -aG uucp $USER
5) Ok, we're logged back in, we're plugged in, and the board is wired per above. Let's do some triage.
./muforth -d bootloader -f target/ARM/board/stm32f0-discovery.mu4
---- loading messages scroll by ----
(( STM32 serial bootloader support )) <--- This is important
(( ST-LINK debug No supported USB devices found )) <--- Ignore this, it's spurious noise
boot
Bootloader Version 3.1 <---
Using extended erase command. | <---------- You want to see this after typing boot
Ok (chatting) (hex) (flash) <---
@flash t.erase
NOW HIT THE BLACK RESET BUTTON ON THE BOARD
boot
Bootloader Version 3.1
Using extended erase command.
Ok (chatting) (hex) (flash)
@flash du
.... and you should see all ffffff's
Groovy. Unplug and reconnect with the board with a normal command string:
./muforth -f target/ARM/board/stm32f0-discovery.mu4
jtag
ST-LINK/V2 JTAG V15
DFU mode => Mass mode => Debug Mode
SP RP IP
ffffffe0 00000000 00000000*
WARNING: Target's flash image differs from host's. Run flash-image? Ok (chatting) (hex) (flash)
flash-image
erase page 800_0000
program 800_0000 200
program 800_0200 200
erase page 800_0400
program 800_0400 1b8 (Ok) (chatting) (hex) (flash)
verify Ok (chatting) (hex) (flash)
PRESS THE BLACK RESET KEY ON THE BOARD
jtag
ST-LINK/V2 JTAG V15
Debug Mode
SP RP IP
20001efc 00000000 00000000* Ok (chatting) (hex) (flash)
@flash du should show, starting from address 08000000, an address in ram (20002000) followed by a bunch of
addresses in 08000000 land
Bad Flash Happens
Sometimes Things Go Wrong and you find you have a dev board in a state where you can't do anything with flash, which is now mysteriously filled with Really Weird Shit. Today's procedure covers the very recent unwedging of an STM32F051-Discovery board. Don't ask us how it happened, this board showed up in this state.
You have to sidechannel via the serial bootloader
Normal jtagging via muforth/stlink is not going to work. You have to use the serial bootloader. In the example below, we're using a PL2303, but this will work with an FTDI-2232H etc. You just need something that will do serial that has TX, RX, GND and 3.3V.
1) Put female-female jumper wires on the following pins of the PL2303: RXD, TXD, GND, 3.3V
2) Jumper BOOT0 and VDD on the F051 board with a wire or one of those nifty jumper pins pirated off one of your other boards.
3) Attach the PL2303 to the F051 board as follows:
... and plug it into a usb port.
4) When you build muforth on Linux, it automagically decides muforth/mu/serial-target should symlink to /dev/ttyS0. This needs to change because it's a nervy assumption. In this case, the PL2303 will enumerate as /dev/ttyUSB0. Let's get things set up.
One more "gotcha" --- not all systems have the same idea about which device belongs to which group. Archlinux, for example, decided that this /dev/ttyUSB0 belonged to group uucp, so if you're not a member, you need to add yourself to that group, logout and log back in.
5) Ok, we're logged back in, we're plugged in, and the board is wired per above. Let's do some triage.
Groovy. Unplug and reconnect with the board with a normal command string:
... and that's it, you should be good to go. ;)