FLASH programming and concurrent code execution

[domen23]

Posted on October 06, 2010 at 11:14

FLASH programming and concurrent code execution

[cschumann]

Posted on May 17, 2011 at 14:10

Hello Domen,

The Corex-M3 is build based on a harvard architecture. That means you have different busses for instruction and data (see the performance line block diagrams for example) named IBus and DBus. While the IBus goes directly to the flash interface, the DBus goes to the ''Bus Matrix'' which multiplexes between several sources/destinations. To write to the internal flash, you take the way from the matrix to the flash interface. Writing values to the flash takes about 50us, erasing a flashpage takes a maximum of 40ms(!). Both operations are blocking to the flash and you cannot read data. (see PM0075

http://www.st.com/stonline/products/literature/pm/17863.pdf

). This means you cannot read instructions if you are executing your code from flash. As the Cortex-M3 has no instruction cache, the only instructions you can execute are the instructions that are alredy in the pipeline. You can get around that issue by executing code from the SRAM while writing to the flash (very difficult if interrupts are used) or by erasing the flash pages while the processor is mostly idle. We are using some flash pages as a ring buffer with at least one empty flash page (to which we can write data immidiately). Remember: Writing is cheap, erasing is expensive. If you need to write your data frequently I suggest using an external EEPROM (i.e. M95512) or using FRAM. Best regards Carsten Schumann

[Tesla DeLorean]

Posted on May 17, 2011 at 14:10

Here's a symptom I noticed: while programming flash (code is running from flash too, just other location), USART misses some characters.

Yes this can be a problem. The USART isn't missing the data, you get overruns because you are not servicing it promptly. In fact most CPU with flash like this can't write and execute at all, the STR9 has two banks to permit one to execute while the other writes. The common solution is to run flashing code from RAM. Most members of the STM32 have a single bank of flash, if you execute out of flash it will block during the write operations. You need some kind of flow control on the serial port to prevent data loss, either something like CTS/RTS DSR/DTR, or using a protocol like XMODEM where you can hold off the sender by sending the ACK/NACK after the flash has been written. In this regard YMODEM-G doesn't make a lot of sense as it streams the data with no way of stalling it. The STM32 really needs a hardware FIFO on the USART, You might be able to mitigate that with DMA.

[damh]

Posted on May 17, 2011 at 14:10

The timing values for erasing the flash with stm32 aren't really convincing.

It is extremly temperature, supply voltage and erase-cycle-number dependend! With every erase-cycle it will be slower. DMA should solve your problem, but you should remember, that it costs a lot of supply current. Interruptvectortable and interruptcode in RAM should solve it, too.