SoC
  • Home
  • Arm
  • Arm Cortex M0/M0+
  • Arm Cortex M4
  • Arm Cortex M3
  • Contact
Reading: Cortex-M3 Flash Memory Limitations and Workarounds
SUBSCRIBE
SoCSoC
Font ResizerAa
  • Home
  • Arm
  • Arm Cortex M0/M0+
  • Arm Cortex M4
Search
  • Home
  • Arm
  • Arm Cortex M0/M0+
  • Arm Cortex M4
Have an existing account? Sign In
Follow US
  • Looking for Something?
  • Privacy Policy
  • About Us
  • Sitemap
  • Contact Us
© S-O-C.ORG, All Rights Reserved.
Arm

Cortex-M3 Flash Memory Limitations and Workarounds

David Moore
Last updated: October 5, 2023 9:55 am
David Moore 11 Min Read
Share
SHARE

The Cortex-M3 processor has some limitations when it comes to its internal flash memory. While the amount of flash available is generally sufficient for most applications, developers may run into issues as their code size increases. Additionally, there are some quirks with how the flash memory is accessed and erased that need to be accounted for. This article provides an overview of the key flash limitations on Cortex-M3 devices and suggests potential workarounds to mitigate them.

Contents
Small Internal Flash SizeFlash Access TimingFlash Page Erase SizeFlash Wear LevelingLimited Flash Write CyclesFlash Read Disturb EffectsFlash Memory CorruptionFlash Memory DeadlockUnpredictable Code Execution from FlashFlash Memory ShortsLimited Flash Patch CapabilitySingle BIT Errors in FlashFlash Memory Reads Disturbing GPIOThe Flash Interface Has Single Point of FailureSummary

Small Internal Flash Size

The total flash memory size for Cortex-M3 chips can range from 32KB up to 1MB. While this is enough for many simple applications, larger and more complex programs may exceed the available space. Developers should be aware of their total flash usage throughout their project to avoid issues. There are a few ways to work around the limited internal flash:

  • Optimize code to reduce size. Removing unnecessary library functions, enabling compiler optimizations, and avoiding duplication can help reduce the space needed.
  • Split firmware into multiple images that are loaded separately. Less-used functionality can be placed in a secondary image loaded only when needed.
  • Use external flash chips. Adding an external SPI flash chip allows for much more total space for code and data storage.
  • Store static data in external EEPROM/FRAM chips to save space.

Flash Access Timing

The Cortex-M3 needs to disable interrupts for certain flash memory operations. These include erasing pages, writing to flash, and updating flash mapping tables. With interrupts disabled, any pending interrupts will not be handled until the flash operation completes. Real-time and time-sensitive operations may be impacted.

Typical page erase times are a few milliseconds, while individual write cycles may take microseconds. Developers should plan for worst-case interrupt latency by avoiding flash operations in critical interrupt handlers. When possible, perform flash writes in the application background loop instead. The impact can also be mitigated by keeping ISRs short and avoiding flash access there when feasible.

Flash Page Erase Size

The smallest unit that can be erased in Cortex-M3 flash memory is one page. Page sizes vary but are commonly 2KB to 4KB. This means that to modify even 1 byte, an entire page must first be erased. Doing frequent small writes to flash can therefore be inefficient.

To work around this, structure data written to flash in larger multi-kilobyte blocks that align with page boundaries. Optimize the firmware to group related data together that is updated at the same time. Buffer writes in RAM and commit them to flash in batches as needed.

Flash Wear Leveling

Flash memory cells have a limited program-erase cycle life before degrading. Typically 10,000 to 100,000 cycles are guaranteed. If certain flash pages are rewritten frequently while others rarely change, the uneven wear can shorten the usable lifespan.

To maximize endurance, wear leveling techniques help spread writes across all available blocks. This is not implemented in hardware for Cortex-M3 flash. The firmware instead needs to manage logical to physical mapping to track wear. Common techniques include sector rotation and starting writes at different offsets.

Limited Flash Write Cycles

The total flash write cycle limit can present issues for data logging and other highly write-intensive applications. Exceeding the maximum ratings for a device will reduce its usable lifespan. There are a few ways to mitigate this:

  • Add external persistent storage like SD cards or USB drives which have higher write cycle ratings.
  • Use RAM buffering to collect data before writing to flash, reducing total writes.
  • Split variable writing across multiple flash sectors to spread wear.
  • Design firmware to allow worn out flash sectors to be marked bad and avoided.

Flash Read Disturb Effects

Aggressive flash reading at high frequency can potentially corrupt or alter stored data bits in flash memory cells. This is due to read disturb effects where repeated reads can cause charge leakage over time. The impact increases at higher operating temperatures.

To avoid issues, design firmware to: – Minimize unnecessary redundant reads from flash memory – Add delays between read accesses from the same sector – Refresh flash pages after heavy repeated reads by rewriting stored data – Increase flash operating margins to leave room for charge leakage

Flash Memory Corruption

Power failures, glitches, and crashes during flash write sequences can result in corrupted data. The system may not detect errors immediately but later observe invalid stored values. To safeguard against corruption:

  • Avoid accessing flash during power transitions when supply levels may be unstable.
  • Use checksums or CRC values to verify data integrity of critical flash data.
  • Implement logic to detect bad/corrupt sectors and remap or restore data.

Flash Memory Deadlock

If flash operations are incorrectly sequenced in firmware, deadlock conditions could occur where the system gets stuck waiting on flash hardware and becomes unresponsive. For example, attempting to erase a block that is midway through a write cycle. Always check that flash operations have completed before starting a new one.

Additional tips to prevent deadlocks:

  • Structure code so flash routines are only called from a single task or thread.
  • Disable/pend other flash access requests while any operation is in progress.
  • Use watchdog timers to catch stuck flash routines and reset the system.

Unpredictable Code Execution from Flash

The Cortex-M3 flash memory interface allows fetch requests and write requests to happen concurrently. This means new code can be written to a flash sector while existing code from that sector is still executing. This could lead to unpredictable program flow if code gets modified mid-execution.

To avoid unintended program behavior:

  • Mark code sections as read-only whenever possible.
  • Flush instruction pipeline after writing new code to flash.
  • Restrict code updates to well-defined points, forcing an entrypoint reboot.

Flash Memory Shorts

In rare cases, flash memory cells can short circuit, getting stuck in a low resistance state that always reads as erased. This effectively creates bad blocks that always read 0xFF. These failure points increase with wear. To mitigate:

  • Implement bad block detection and mapping to avoid worn out flash sectors.
  • Use error correcting codes that can detect and correct bits stuck in erasure state.
  • Write complementary data pairs across multiple cells to identify shorts.

Limited Flash Patch Capability

Due to the page erase requirements, directly patching flash code is often unfeasible. Any modifications require an entire sector to be erased and rewritten. For large firmware images, patching even small sections is cumbersome.

Potential mitigation strategies include:

  • Reserve blank space in each sector to allow for future patches.
  • Use indirect branching via function pointers stored in RAM patch areas.
  • Design separate patch code sections that can be toggled.

Single BIT Errors in Flash

Flash memory is susceptible to bit errors, where stored bits spontaneously flip state. Single bit flips are possible in flight during radiation exposure. Multi-bit errors are less likely but can still occur.

To detect and recover from bit errors:

  • Use parity or ECC codes to detect incorrect bits.
  • Duplicate critical data across multiple flash sectors.
  • Perform periodic scrubbing to detect and correct bit flips.

Flash Memory Reads Disturbing GPIO

Due to the shared bus architecture, flash memory accesses can impact other peripherals on Cortex-M3 MCUs. Specifically, GPIO ports may glitch during flash reads if the two peripherals are on the same bus. Steps to avoid issues:

  • Configure flash and GPIO on separate buses/memory regions if possible.
  • Disable GPIO interrupts during flash read cycles.
  • Fix GPIO outputs after flash access if glitches are problematic.
  • Minimize unnecessary flash reads to reduce chances of disturbance.

The Flash Interface Has Single Point of Failure

The flash memory interface is a key piece of system infrastructure. If the flash controller peripheral fails due to defect or damage, system firmware and data may become inaccessible. Consider the following hardware redundancy techniques:

  • Use flash parts with multiple independently accessible banks/planes.
  • Implement custom logic mirroring flash to secondary chip or bus.
  • Use error correction coding to recover from failures.

On the software side, compartmentalize code into regions with separate flash interfaces. This way a localized failure only impacts a subset of functionality.

Summary

In summary, Cortex-M3 flash memory has limitations in its size, access timing, erase requirements, wear endurance, and susceptibility to errors. Careful firmware design can mitigate most issues by minimizing unnecessary writes, spreading wear evenly, verifying data integrity, and recovering from failures. Adding external storage can also help overcome size and endurance restrictions in data-intensive applications. Understanding these nuances of integrated flash memory leads to more robust Cortex-M3 system design.

Newsletter Form (#3)

More ARM insights right in your inbox

 


Share This Article
Facebook Twitter Email Copy Link Print
Previous Article Binary Image Files vs Formatted Firmware Files
Next Article When to Use Intrinsics vs Assembler for Math Functions on Cortex-M4?
Leave a comment Leave a comment

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

2k Followers Like
3k Followers Follow
10.1k Followers Pin
- Sponsored-
Ad image

You Might Also Like

STM32F1(Cortex-M3) SRAM Boot Magic Values

The STM32F1 microcontroller based on the Cortex-M3 core contains several…

8 Min Read

How Many Interrupts Are Available in the ARM Cortex-M3/M4?

The number of available interrupts in ARM Cortex-M3 and Cortex-M4…

8 Min Read

Troubleshooting errors when running make_mmi_file.tcl

Running into errors when trying to generate MMI files using…

6 Min Read

ARM Cortex M4 Boot Process

The ARM Cortex M4 is a 32-bit core integrated in…

7 Min Read
SoCSoC
  • Looking for Something?
  • Privacy Policy
  • About Us
  • Sitemap
  • Contact Us
Welcome Back!

Sign in to your account