8
\$\begingroup\$

Most ARM Cortex M MCUs do not feature EEPROM memory. Instead, persistent data can be written to the same flash memory that also holds the program.

  • What is the state of the CPU during this erase/write process?
  • Does it halt? Does it maintain normal operation?
  • Does the behavior of the CPU depend on the specific MCU family (e.g. STM32, Kinetis L) used?

(To some people this could look like a stupid question, but Microchip's PIC16 halts the CPU for up to 40ms during flash self-programming.)

\$\endgroup\$
  • \$\begingroup\$ Do you have reference about PIC16 halt? \$\endgroup\$ – Daniel Grillo Oct 8 '13 at 18:49
  • \$\begingroup\$ @Wouter Which ones? Have you tested it, say with an interrupt entirely executed in RAM? \$\endgroup\$ – starblue Oct 8 '13 at 19:51
  • 2
    \$\begingroup\$ Contrary to what I commented before reading from their UserManuals the NXP chips seem to disable only the flash interface during In Application Programming, so an interrupt that runs entirely from RAM might be possible during the Flash erase or write time. But this largely unxplored territory, I could for instance imagine timing problems when the interrupt takes substantial time, with consequences for the Flash endurance. \$\endgroup\$ – Wouter van Ooijen Oct 8 '13 at 20:55
  • \$\begingroup\$ Yes, They have no eeprom but, for this situation some Cortex-M like ST32 has backup register that you can save your information on there and about PIC16, i think it is an interesting thing. please mention your source about PIC16.(Datasheet?) \$\endgroup\$ – Roh Oct 9 '13 at 5:43
  • \$\begingroup\$ @Wouter Yes, timing could be a problem. Except for the LPC8xx the "Copy RAM to flash" IAP commands take the clock frequency as a parameter, so I suspect they use a simple delay loop. \$\endgroup\$ – starblue Oct 9 '13 at 11:41
4
\$\begingroup\$

The behavior of the core does depend on the implementation. The Flash is not integral to the ARM core, and as such, every vendor implements it differently. Typically, during the erase/write process one would execute from RAM, and execution should not be affected.

On the STM32, I believe reads from flash stall while erase/write cycles are ongoing. This would cause the core's execution to stall until the operation completes. With some of the flash configurations, I believe you can continue to execute/read flash and it will only stall when you access the part of the flash that you are eraseing/programming.

I've used other Cortex M's where you must execute from RAM while modifying flash contents otherwise you will encounter a bus fault (and likely a system crash if your bus fault/hard fault handlers are in flash). Some micros with large amounts of flash implement it as two independent flash arrays, and these typically allow for full access to one bank while operating on the other.

You would need to refer to the documentation for your specific part to see the limitations of execution while modifying flash contents.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.