In-Application Flash Programming - Sanity Check

[Joe.H]

I've written many bootloaders for Freescale/NXP Kinetis mcus - this is my first for a STM32F4.

I'm not using Cube or HAL.

In my prior bootloaders, an executable program stub was moved to ram and executed because a flash read could not take place during a flash erase/program operation.

I'm using the STM32F427 mcu.

The documentation states the same (no flash read during a flash erase/program).. More specifically, it states the mcu will stall until the flash erase/program operation is completed.

In reviewing your HAL code - I don't see the use of ram based executable code and I see the following ...

FLASH->CR |= FLASH_CR_STRT; // Start Erase

while(FLASH->SR & FLASH_SR_BSY); // Wait til finish

Is the "while" processing taking place out of the ART or is it just stalling until the instructions associated with the while test can be executed?

Would it be a more robust process to have the code above executed from ram so that no buss stall will occur during the busy test?

Another question: If User option Read Protection Level 1 is set - can In-Application Erase and Programming still take place?

To re-program flash while in Level 1 - can the Level 1 protection stay active or do you have to take Read protection back to level 0 (I hope not since the documentation says all user data is erased - which would include the bootloader)

Thanks

[Tesla DeLorean]

It stalls, ie stuffs wait states, if the FLASH core is currently mid write/erase. Everything proceeds normally. The ART might hide some of that, but it will be short lived.

To avoid that hit to real-time operation, the vector table, and all interrupt handlers, code and subroutines they might call, need to be in RAM. Given the rather heavy burden of achieving that most of the examples don't try.

You might grep "ramfunc", but only seem to remember some L1 examples many moons ago.

[Bob S]

In my systems, all real-time features are disabled before downloading/programming new firmware. All code in in Flash and I just live with the loooong pause during flash operations. The F42x parts have (at least) 2 banks of FLASH, which allows code running from one bank to erase/program the other bank without stalling the CPU (see "read-while-write" in the reference manual). So your bootloader code can be running in one bank and erasing/programming the application in the other bank with no pauses. If you have to erase/program the same FLASH bank and you have a tick counter running off the SysTick interrupt, you will loose time during the erase cycles as they are much more than 1ms long (and the interrupt routine can't run). But that is the worst effect.

In RDP 1, yes, the CPU itself can erase and program FLASH. You don't need to go to RDP 0, and in fact, trying to go to RDP 0 will trigger a bulk erase of FLASH (depending on other protection settings).