7

On the STM32F103, the erasing of a flash page takes 20ms during which the core stalls for me. It's not clear from the ST PM00042 Flash programming manual whether the core would always stall when erasing a flash page or whether it just stalls because the instruction stream itself is in flash memory (in my project) and the FPEC (the flash memory interface) is busy and can't fetch more instructions.

Another way to ask this question is "would running my flash programming code from RAM avoid the flash page erasing stall?".

Thanks,

artless noise
  • 21,212
  • 6
  • 68
  • 105
Captain NedD
  • 337
  • 1
  • 5
  • 11

2 Answers2

7

I believe that during flash programming, any attempted access to flash will stall the CPU.

So what you want to do is ensure that the critical code (maybe interrupt handlers, watchdog kicker, etc) can be run out of RAM during a program operation. The last time I used the STM32 (probably ~2 years ago) that's exactly what I did.

So just to be clear, to answer the question at the end of your post:

Another way to ask this question is "would running my flash programming code from RAM avoid the flash page erasing stall?".

I believe the answer is "no". It doesn't matter so much where the flash programming driver is located, what matters is what your code does while the erase / program operation is in progress. If the CPU tries to access flash during an operation, even to read instructions for your program or read a table of constants, I believe it will stall.

I know for a fact that this is how the NXP flash works on their ARM uCs, but I wanted to cite chapter & verse for the STM32 as well. For some reason, the flash programming manual seems to be unavailable right now, but I found the following language in a similar document (PM0068, I believe):

An ongoing Flash memory operation will not block the CPU as long as the CPU does not access the Flash memory.

and

If a read/write operation [to flash] is initiated during programming, (BSY bit set), the CPU stalls until the ongoing main Flash memory programming is over.

Dan
  • 10,303
  • 5
  • 36
  • 53
  • Awesome, thanks. What I'm doing at the moment is trying to load the offending code into RAM to try this out. I'll let you know how I fare. I just wish PM00042 was as clear as the PM you quote... – Captain NedD Aug 10 '10 at 04:01
  • PM00042 has disappeared - try looking for PM0056 or PM0063. You can also go to the ST website, find the STM32 section and look for the "Programming Manual" documentation. – peter_mcc Oct 22 '12 at 11:04
  • It is the bus that stalls, not the core. The core simply inserts wait states (spins it's wheels) waiting in the bus. – Clifford Jul 09 '23 at 18:38
0

It is the bus that stalls, not the core. The core may have to wait in the bus if course.

The SRAM and Flash are on separate buses, so code can continue to execute from RAM.

You would have to be sure that that code does not make calls to code in flash, and also be aware that counter-intuitively perhaps SRAM code execution will be slower because both instruction and data fetches are on the same bus so no longer occur simultaneously.

Similarly code in external SRAM can continue to run. The separate bus may overcome the data/instruction contention issue, if you arrange for one to be in internal, and the other in external RAM, but, the external bus is slower in any event, so performance will still be affected.

The issues and compromises are such that you might consider using a separate EEPROM for NV storage.

Clifford
  • 88,407
  • 13
  • 85
  • 165