2015-09-10 05:12 AM
We are using STM32LL476QE and as per reference manual , While executing a program code from bank 1, it is possible to perform a program operation on the bank 2.
Here we are into situation in which Our custom Bootloader will be executing from BANK1 and will be writing Application Binary on BANK1 itself at the time of update, will that work or we need to execute flash program and erase API's from RAM? We are using GNU ARM tool-chain from https://launchpad.net/gcc-arm-embedded Can you please suggest some robust method to do this ? #stm32l4xx2015-09-10 06:54 AM
Hi horaira,
RM0351 provides the following answer:''An on-going Flash memory operation will not block the CPU as long as the CPU does not access the same Flash memory bank. Code or data fetches are possible on one bank while a write/erase operation is performed to the other bank.On the contrary, during a program/erase operation to the Flash memory, any attempt to read the same Flash memory bank will stall the bus. The read operation will proceed correctly once the program/erase operation has completed.''-Mayla-To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2015-09-10 02:12 PM
In other words, it works as with (most?) other STM32-models: if you want to run code simultaneously while writing to (or erasing a block) FLASH (e.g. the communication used cannot tolerate a lag imposed by the write), it must reside in a different memory or a different FLASH bank (if any), including ISRs. Otherwise, as Mayla wrote above, the processor will simply stall until the write completes and happily resume after.
JW2015-09-23 08:04 AM
Thanks,
One more question related to this, Scenario: Code is executing from BANK1 and doing erase/program operation on BANK2 Does this operation is interruptible, i.e. can any High priority interrupt or Task preempt it? Any side effect ? Thanks in advance2015-09-23 09:58 AM
Well it's not part of the processor core, the flash controller will keep doing what it was doing until completion and the processor can run doing it's thing.
If you look at or touch BANK2 while it's erasing or writing, you can expect processor execution to stall until the operation has completed, and then respond to the access request.