STM32F4 - Flash stall -- more info

[dibs]

Posted on February 12, 2014 at 15:07

I have been reading conflicting reports on writing/reading to/from FLASH when running your program code from FLASH as well.

First of all, where is there documentation saying that you can stall the processor by doing this with an M4? I read the programming manual and the reference manual, and I don't see it there.For instance, let's say that I have my program code running in Sectors 0-3 and want to use Sector 4 for configuration code. Also, I need to be able to read, write, and erase my config code after executing main.What does it mean to stall the processor? Does this mean that we cannot access FLASH indefinitely, or until the current FLASH operation is writing? If I am writing to memory location in one sector, can I read from a memory location in another sector at the same time?If the processor stalls (lets say I have a 168MHz clock and 5WS), can we know the maximum length of the stall? Assuming we knew the operation, it would be different for a sector erase or for a read.During a processor stall, what stops working? Do my peripherals still function? Will I miss interrupts? #stm32f4 #flash #flash

[Tesla DeLorean]

Posted on February 12, 2014 at 18:37

The time is specified in the manuals, and relates to the erase/write times of the cells. This will depend on the age, voltage, and charge-pump performance. The flash is self-timed, so will not be affected by clock speed.

The stall will occur as a finite number of wait states, the read that triggers it will totally stall the processor until complete. So ANY read, to ANY portion of the BANK during an ERASE/WRITE will stall. Peripherals will keep going, Interrupts will NOT be serviced while the processor is stalled. And clearly running an interrupt or vector table through the flash will also precipitate a stall. The performance will be non-real time, peripherals may over/under flow as a result. If using the USART collect a large block of data, and use a flow-control protocol.The 2MB F4 devices have TWO banks, you can run from one whilst working on the other.

[Tesla DeLorean]

Posted on February 12, 2014 at 18:42

Worst case stall on a 128 KB sector is of the order of 2-4 SECONDS as I recall. And up to 32 for a Mass Erase, but clearly you can't be running code in a single bank in such situations.

[dibs]

Posted on February 12, 2014 at 19:16

Ah, I was looking in the wrong place for those tables. (Tables 39-40 in device datasheet Rev4).

In the instance where you have program code and configuration values in the same FLASH bank, is it actually catastrophic to write to FLASH? I am assuming that the core will halt its executions until the FLASH is no longer busy. Is this correct?Also, let's say that I want to use that setup to get config values upon start up. Should I try to branch to a piece of code that shoves this data into SRAM before main? Or should I just make sure that I deal with all of my FLASH needs before initializing the rest of my program?

[Tesla DeLorean]

Posted on February 12, 2014 at 19:46

It's not catastrophic, but might be undesirable. The core seizes up during the read attempt, and then continues seamlessly when done. One would generally want to avoid erasing a sector you're currently running from, this most likely results in a Hard Fault.

Yes, I'd look to manage as much work on the flash to the reset path prior to main application execution. Especially any erasure work. Writes might take several micro-seconds which could perhaps be more tolerable. I've used XMODEM in flash to update devices, so I can write blocks prior to sending an ACK back to the host and it has in-built flow control in the manner desired. Things like YMODEM-G where the stream is more continuous will likely cause more issues than it solves.

[jpeacock2399]

Posted on February 12, 2014 at 21:25

Another consideration is using a watchdog timer while erasing flash.  Either IWDG or WWDG will time out on a long erase, so you have to move the erase code to a RAM subroutine.  RAM doesn;t stall so you can continue to poll/reset the watchdogs while erasing.

No reason you can't save parameters in the internal flahs, just eb careful about the floorplan for memory in the linker script.  I exclude sectors 3 and 4 (last two 16KB sectors on an F2/F4) or the last two sectors on an F1 from the link memory map so no code is stored in either sector.  I write the primary copy of parameters to the first sector and a backup to the second, both with CRC checksums.  Worst case if one is corrupted the application will still run. I've used this scheme for several years and it's proven very reliable in the field.  It handles power failure or program crash during an update, since there's always a backup copy.   Jack Peacock