STM32F205 Flash Programming

[ramv]

Posted on October 18, 2012 at 20:11

To erase a sector, follow the procedure below:

1. Check that no Flash memory operation is ongoing by checking the BSY bit in the FLASH_SR register

2. Set the SER bit and select the sector (out of the 12 sectors in the main memory block) you wish to erase (SNB) in the FLASH_CR register

3. Set the STRT bit in the FLASH_CR register

4. Wait for the BSY bit to be cleared

 The last step states we have to wait until BSY bit is cleared in the FLASH_SR register meaning we have to sit in a loop reading the FLASH_SR register until the BSY bit is cleared. Here is where  need some clarification.

The Flash programming manual also states that we can’t access/read the flash when the write operation is taking place. If our code for programming flash resides in flash, how can we read the FLASH_SR register to check the BSY bit is cleared if we can’t access from it (bus stall is mentioned).

Does that mean flash erase routines have to be moved to internal SRAM to check the FLASH_SR register OR does the M3 processor automatically fetch the instruction to read FLASH_SR after the erase is completed.

If this is the case, can it be guaranteed that there won’t be any unforeseen issues in this polling loop trying to read the FLASH_SR register when the erase operation is taking place.

[Tesla DeLorean]

Posted on October 18, 2012 at 20:33

If the processor tries to read from flash it stalls. This is achieved by stuffing wait states, hundreds of thousand of them. This could result in nothing happening for seconds.

It could stall reading the instruction, or the literal, your systick interrupt, doesn't matter much. It is likely to appear that by the time it reads the register it is done. If you want things to keep running (interrupts, etc) run from RAM.

[ramv]

Posted on October 19, 2012 at 16:26

Thanks for the reply. There is no mention anywhere in the ST Micro Datasheet/Manual that the routines needs to be run from internal SRAM. Also is the SRAM enough to run these routines or does it need external SRAM mapped through the FSMC ?

If this is truly the case, do we just copy the Flash programming routines and checking of the register to internal SRAM?

[Tesla DeLorean]

Posted on October 19, 2012 at 17:05

How long is a piece of string?

Whether it will fit is going to be a function of how large it is, and how much RAM you have. The internal SRAM should be quite sufficient to hold routines capable of flashing the device. What would it take? a couple of thousand bytes, several hundred? You have to put everything you need in SRAM, so if you have interrupts running the Vector Table, Interrupt routines, etc, will ALL need to be in SRAM. ANYTHING that touches FLASH will cause the processor to STALL. The best time to do it is immediately post reset, without any interrupts running, using small compact assembler routines with a very clearly understood call tree, and use of resources. The code does NOT need to run from SRAM, in most devices flash is completely unusable while writing/erasing, the STM32 hides this limit from you by stalling. While this is transparent, it does preclude real-time operation, and will cause peripheral overruns/underruns. Whether you run from FLASH or SRAM is really your choice.

[ramv]

Posted on October 19, 2012 at 19:51

If anything that touches the flash can stall it, I have no choice but to run the code from SRAM during erase/program the flash right ?

[ramv]

Posted on October 19, 2012 at 19:51

[Tesla DeLorean]

Posted on October 19, 2012 at 20:38

If anything that touches the flash can stall it, I have no choice but to run the code from SRAM during erase/program the flash right ?

No, you have a choice, stalling in not fatal to the processor, it provides transparency which you may or may not be able to deal with. It will depend on what you're doing, and how you're doing it. I can use XMODEM code in one section of flash to program another section, works fine. The protocol serializes the process so the amount of time it takes to write the flash is just the latency in sending the ACK/NACK to get the next block.

[ramv]

Posted on October 07, 2013 at 16:14

Is it just a matter of copying the flash erase routines to SRAM and executing from it or do I have to boot from Embedded SRAM (Boot0 and Boot1 = 1) ?

[Tesla DeLorean]

Posted on October 07, 2013 at 17:18

That would entirely depend on what you plan on doing, and the level of robustness you are looking to acheive.

I, personally, would not recommend erasing the device completely, but keeping a boot loader (16K) that doesn't get erased, and that arbitrates access to other portions of flash which do. You can copy and jump to code in RAM any time you choose, understand what it's currently be used for. Changing the BOOTx pins is not required, the code execution will go where you point the PC, but it would permit code you have moved there to boot if the device resets. This would not protect you if the power failed, and you had the whole device erased. If you erase the whole device your recovery routes for the bricked device are basically via the System Loader (Serial, USB-DFU, etc) and JTAG/SWD