Improper setting or omission of flash latency value of FLASH_ACR for STM32F407G

[anarchitech]

Help Help, My Flash Is Wedged!

An improper setting of or omitting to set FLASH_ACR on the STM32F407G-discovery board will cause flash to become locked and the user will be unable to read or write to the flash, including reflashing the chip without the following procedure.

It is critical to match the FLASH_ACR value with the voltage correctly. cf: ST Reference Manual RM0900, en.DM00031020.pdf pages 80-112 for description. Basically, if you do not, on the next attempted use of flash ST's boot ROM code will lock the flash and you will be unable to read or write to it.

Procedure for Resetting

1. With the board unpowered, jumper between the BOOT0 and VDD pins.

2. Enter the following sequence carefully. Example shows flashing the chip with the factory demo code covered in the workaround in st demo code STM32F4-Discovery board causes breakage #18.

$ cd muforth/mu

$ ./muforth -f target/ARM/board/stm32f4-discovery.mu4 ram -f target/ARM/v6-m/kernel-itc.mu4 load-image stm32f407.img

    jtag
    00 RCC_CFGR !
    00 t.erase
    jtag
    flash-image
    verify

3. Re-power the board and reconnect, everything should be working.

[anarchitech]

daf mentioned this today, and it's an excellent point:

"Btw: only use 0 (or 00) t.erase on the f407. 
The other stm32 devices, like the f051, use 
paged flash and require an *address* rather 
than a sector number, to erase. 
t.erase is not really for end user use; it's 
really just a primitive for flash image, which
 knows what kind of flash you are using. 
So be careful with that."

In point of fact, I have a nicely wedged f0 in my box of testing boards that can attest to what happens if you use t.erase on it.
Take heed, bitbangers.