Optimizing Cortex-M Flash Wait States for Performance and Safety

Flash wait states (access latency) represent one of the most critical hardware configuration parameters on ARM Cortex-M microcontrollers. While modern Cortex-M cores (Cortex-M3, M4, M7, M33, M55, M85) easily clock between 72 MHz and 1 GHz, embedded NOR flash memory physics impose fundamental access delays of 20 ns to 40 ns.

If the core clock period is shorter than the flash access time, the memory controller must insert wait states—holding the CPU pipeline while the flash array charges wordlines and sense amplifiers evaluate bit cells.

In safety-critical applications governed by standards like ISO 26262 (ASIL D), IEC 61508 (SIL 3/4), DO-254/DO-178C (DAL A), and IEC 62304, flash timing configuration is not just a performance knob; it directly impacts Worst-Case Execution Time (WCET), instruction bus integrity, and hardware fault injection resilience (ECC/parity errors).

+-------------------------------------------------------------------------------+
|                           ARM Cortex-M Core Engine                            |
|                                                                               |
|  +--------------------+    ICode / DCode Bus    +--------------------------+  |
|  | Execution Pipeline | <=====================> |  Flash Memory Controller |  |
|  +--------------------+                         +--------------------------+  |
|            |                                                 |                |
|            | Core Clock (168 MHz = 5.95 ns)                  | Access Delay   |
|            v                                                 v                |
|  1 CPU Cycle = 5.95 ns                              Flash Array = ~35.7 ns    |
|                                                     (Requires 5 Wait States)  |
+-------------------------------------------------------------------------------+

The Physical Mechanism Behind Flash Wait States

Embedded non-volatile flash (eFlash) consists of floating-gate or charge-trap transistors. Reading a flash cell requires pre-charging bitlines, driving wordlines to a reference voltage, and allowing differential sense amplifiers to discriminate between programmed (charged) and erased states.

This analog sensing process has a fixed physical delay: $T_{acc} \approx 20\text{ ns to }35\text{ ns}$.

Total Flash Access Time = (LATENCY + 1) * T_CPU_CLK

Where:

• $\text{LATENCY} = 0\text{ WS} \implies \text{Access completes in } 1\text{ CPU clock cycle}$.
• $\text{LATENCY} = 1\text{ WS} \implies \text{Access completes in } 2\text{ CPU clock cycles}$.
• $\text{LATENCY} = N\text{ WS} \implies \text{Access completes in } (N + 1)\text{ CPU clock cycles}$.

Theoretical Wait State Boundary Example

Assuming a typical flash access delay of $T_{acc} = 30\text{ ns}$:

If the CPU clock runs at 168 MHz (5.95 ns per cycle) and software configures 0 wait states, the core will sample the ICode data bus at 5.95 ns—long before the flash sense amplifiers settle. The result is bus noise, decoding garbage opcodes, executing invalid instructions (Undefined Instruction UndefFault), or triggering a BusFault / HardFault.

Operating Voltage ($V_{DD}$) and Temperature Dependencies

A common misconception among firmware developers is that lower operating voltages allow fewer wait states. The exact opposite is true.

In CMOS logic and flash sense amplifiers, propagation delay $t_{pd}$ is inversely proportional to supply voltage:

$$t{pd} \propto \frac{C_L \cdot V{DD}}{(V{DD} - V{TH})^\alpha}$$

As $V_{DD}$ drops:

1. Transistor drive currents decrease.
2. Bitline charging and wordline slew rates slow down.
3. Sense amplifier differential resolution takes longer to settle.
4. Flash access time $T_{acc}$ increases, requiring MORE wait states for the same clock frequency.

Official STM32F405/407/415/417 Flash Latency vs. $V_{DD}$ Table (RM0090 Table 5)

[!WARNING] Safety-Critical Mandate (ISO 26262 / IEC 61508 / DO-254): Never tune wait states based on typical bench measurements at $25^\circ\text{C}$ and nominal $3.3\text{V}$. You must select wait states based on the worst-case operational envelope:

1. Minimum possible $V_{DD}$ prior to Brown-Out Reset (BOR) trip (e.g., $2.7\text{V}$ or $2.4\text{V}$).
2. Maximum operating junction temperature $Tj = T_a + (P_D \times \theta{JA})$ up to $125^\circ\text{C}$.
3. End-of-Life (EOL) flash cell degradation after maximum rated write/erase cycles. Violating datasheet timing margins invalidates FMEDA failure rate metrics ($\lambda$) and causes latent field failures under voltage sags or thermal extremes.

Cortex-M Core vs. Vendor Flash Accelerators

It is essential to distinguish between the standard ARM Cortex-M core architecture and vendor-specific flash controllers:

1. ARM Cortex-M3 / Cortex-M4 Core:
   • The core exposes standard AHB-Lite bus interfaces: ICode (instruction fetches from 0x0000_0000 to 0x1FFF_FFFF) and DCode (literal pool constants and debug data).
   • The ARM core itself contains no internal L1 instruction/data cache on M3/M4.
2. Vendor Flash Controllers (e.g., ST ART Accelerator™):
   • Silicon vendors bridge the 32-bit AHB bus to a wide flash interface (typically 128-bit or 256-bit wide flash reads).
   • ST’s ART (Adaptive Real-Time) Accelerator implements:
     • Prefetch Buffer: Reads 128-bit blocks (four 32-bit or eight 16-bit Thumb instructions) on sequential execution.
     • Instruction Cache: 64 lines of 128 bits (1 KB total) storing frequently executed branch targets and loop bodies.
     • Data Cache: 8 lines of 128 bits (128 bytes) for literal pool constant data (.rodata).
3. ARM Cortex-M7 / Cortex-M33 / Cortex-M55 / Cortex-M85 Core:
   • Features built-in hardware Harvard L1 caches (e.g., 4 KB to 64 KB I-Cache and D-Cache) integrated directly into the core, managed via ARM CMSIS System Control Block (SCB_EnableICache(), SCB_EnableDCache()).

+-------------------------------------------------------------------------------+
|                      STM32 ART Accelerator Architecture                       |
+-------------------------------------------------------------------------------+
|                                                                               |
|  ARM Core ICode Bus (32-bit Instructions)                                     |
|        |                                                                      |
|        +---> [ Instruction Cache: 64 lines x 128-bit ] ---> Hit:  0 WS (1 cyc)|
|        |                                                                      |
|        +---> [ Prefetch Buffer: 128-bit Queue ] ----------> Hit:  0 WS (1 cyc)|
|        |                                                                      |
|        +---> [ Embedded Flash Array (128-bit wide) ] -----> Miss: 5 WS (6 cyc)|
|                                                                               |
|  ARM Core DCode Bus (32-bit Data / Constants)                                 |
|        |                                                                      |
|        +---> [ Data Cache: 8 lines x 128-bit ] -----------> Hit:  0 WS (1 cyc)|
|                                                                               |
+-------------------------------------------------------------------------------+

The Critical Clock Frequency Scaling Sequence

When modifying system clock frequencies (such as during bootloader initialization, dynamic voltage/frequency scaling (DVFS), or entering/exiting low-power sleep modes), the order of operations is critical.

+-------------------------------------------------------------------------------+
|                     Clock Frequency Scaling Sequencing Rules                  |
+---------------------------------------+---------------------------------------+
| SCENARIO A: Scaling Frequency UP      | SCENARIO B: Scaling Frequency DOWN    |
| (e.g., 16 MHz HSI -> 168 MHz PLL)     | (e.g., 168 MHz PLL -> 16 MHz HSI)     |
+---------------------------------------+---------------------------------------+
|                                       |                                       |
|  1. Configure NEW higher wait states  |  1. Switch SYSCLK to lower clock      |
|     (e.g., FLASH_ACR = 5 WS)          |     (e.g., RCC_SYSCLKSource_HSI)      |
|                 |                     |                 |                     |
|                 v                     |                 v                     |
|  2. Verify FLASH_ACR latency updated  |  2. Verify clock switch complete      |
|     (Poll FLASH_ACR & LATENCY)        |     (Poll RCC_CFGR & SWS)             |
|                 |                     |                 |                     |
|                 v                     |                 v                     |
|  3. Switch SYSCLK to high PLL clock   |  3. Configure NEW lower wait states   |
|     (e.g., RCC_SYSCLKSource_PLL)      |     (e.g., FLASH_ACR = 0 WS)          |
|                 |                     |                 |                     |
|                 v                     |                 v                     |
|  4. Verify clock switch complete      |  4. Verify FLASH_ACR latency updated  |
|     (Poll RCC_CFGR & SWS)             |     (Poll FLASH_ACR & LATENCY)        |
|                                       |                                       |
+---------------------------------------+---------------------------------------+

[!CAUTION] Fatal Fault Condition: If you increase the PLL frequency to 168 MHz before configuring 5 wait states, the core will attempt to fetch the next instruction at 168 MHz with 0 wait states. The CPU will fetch corrupt opcodes within 1-2 clock cycles, entering a HardFault handler before the register write completes.

Production-Grade, MISRA-Compliant Flash Configuration Code

Below is an industrial-grade, safety-critical flash configuration module for STM32F4 microcontrollers implementing bounded timeout protection, cache invalidation sequences, and proper memory synchronization barriers.

/**
 * @file    flash_latency_ctrl.c
 * @brief   Safety-critical Flash Access Controller and Latency Configuration
 * @details Compliant with MISRA C:2012, featuring bounded timeouts and memory barriers.
 */

#include "stm32f4xx.h"
#include <stdbool.h>

#define FLASH_ACR_LATENCY_MASK       (0x00000007U)
#define FLASH_TIMEOUT_CYCLES         (10000U)

typedef enum {
    FLASH_STATUS_OK              = 0x00U,
    FLASH_STATUS_ERROR_TIMEOUT   = 0x01U,
    FLASH_STATUS_INVALID_PARAM   = 0x02U
} FlashStatus_t;

/**
 * @brief  Configures Flash latency, prefetch, and ART caches safely.
 * @param  target_latency: Desired wait states (e.g., FLASH_ACR_LATENCY_5WS)
 * @param  enable_prefetch: True to enable 128-bit prefetch queue
 * @param  enable_icache:   True to enable instruction cache
 * @param  enable_dcache:   True to enable data cache
 * @return FlashStatus_t: Result code
 */
FlashStatus_t Flash_Configure_Latency(uint32_t target_latency, 
                                      bool enable_prefetch, 
                                      bool enable_icache, 
                                      bool enable_dcache) 
{
    uint32_t timeout_counter = 0U;
    
    /* Validate parameter range (STM32F4 supports up to 7WS) */
    if ((target_latency & ~FLASH_ACR_LATENCY_MASK) != 0U) {
        return FLASH_STATUS_INVALID_PARAM;
    }

    /* 1. If disabling or resetting caches, clear enable bits first (RM0090 Section 3.5.1) */
    FLASH->ACR &= ~(FLASH_ACR_ICEN | FLASH_ACR_DCEN);

    /* 2. Reset instruction and data caches to prevent stale cache entries */
    FLASH->ACR |= (FLASH_ACR_ICRST | FLASH_ACR_DCRST);
    FLASH->ACR &= ~(FLASH_ACR_ICRST | FLASH_ACR_DCRST);

    /* 3. Prepare new ACR configuration value */
    uint32_t reg_val = FLASH->ACR;
    reg_val &= ~FLASH_ACR_LATENCY_MASK;
    reg_val |= target_latency;

    if (enable_prefetch) {
        reg_val |= FLASH_ACR_PRFTEN;
    } else {
        reg_val &= ~FLASH_ACR_PRFTEN;
    }

    if (enable_icache) {
        reg_val |= FLASH_ACR_ICEN;
    }

    if (enable_dcache) {
        reg_val |= FLASH_ACR_DCEN;
    }

    /* 4. Write back configuration to FLASH_ACR */
    FLASH->ACR = reg_val;

    /* 5. Data Synchronization Barrier to ensure register write commits */
    __DSB();
    __ISB();

    /* 6. Verify latency updated with bounded timeout (MISRA C:2012 Rule 14.4 / Dir 4.14) */
    while ((FLASH->ACR & FLASH_ACR_LATENCY_MASK) != target_latency) {
        timeout_counter++;
        if (timeout_counter >= FLASH_TIMEOUT_CYCLES) {
            return FLASH_STATUS_ERROR_TIMEOUT;
        }
    }

    return FLASH_STATUS_OK;
}

Measuring Cycle Impact with DWT and Interrupt Safety

To accurately measure the real performance penalty of flash wait states, developers use the ARM Cortex-M Data Watchpoint and Trace (DWT) Cycle Counter (DWT->CYCCNT).

However, standard naive cycle measurements often produce flawed results due to:

1. ISR Preemption: An interrupt firing mid-measurement pollutes the cycle delta.
2. Compiler Reordering: The compiler moving instructions outside the measurement window.
3. Pipeline Buffering: Incomplete memory writes delaying counter reads.

Cycle-Accurate Measurement Implementation

#include "stm32f4xx.h"

/**
 * @brief Initialize DWT Cycle Counter on Cortex-M3/M4/M7
 */
void DWT_Init(void) {
    /* Enable TRCENA in CoreDebug DEMCR */
    CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
    
#if defined(DWT_LAR)
    /* Cortex-M7 / ARMv7E-M Software Lock Unlock */
    DWT->LAR = 0xC5ACCE55U;
#endif

    DWT->CYCCNT = 0U;
    DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;
}

/**
 * @brief Measures cycle execution time with full interrupt and barrier protection.
 */
uint32_t DWT_MeasureFunction(void (*target_func)(void)) {
    uint32_t start_cycles;
    uint32_t elapsed_cycles;
    
    /* Ensure all explicit memory transactions complete */
    __DSB();
    __ISB();

    /* Disable interrupts to ensure measurement determinism */
    uint32_t primask = __get_PRIMASK();
    __disable_irq();

    /* Memory clobber barrier prevents compiler reordering */
    __asm volatile("" ::: "memory");
    
    start_cycles = DWT->CYCCNT;
    
    __asm volatile("" ::: "memory");
    target_func();
    __asm volatile("" ::: "memory");

    elapsed_cycles = DWT->CYCCNT - start_cycles;
    __asm volatile("" ::: "memory");

    /* Restore interrupt state and flush pipeline */
    __set_PRIMASK(primask);
    __DSB();
    __ISB();

    return elapsed_cycles;
}

Empirical Benchmark: Cache Hit vs. Cache Miss Latency

Consider a 1000-iteration arithmetic workload executed on an STM32F407 running at 168 MHz under varying wait states and cache configurations:

__attribute__((section(".flash_test"), noinline))
void benchmark_loop(void) {
    volatile uint32_t accumulator = 0U;
    for (uint32_t i = 0U; i < 1000U; i++) {
        accumulator += (i * 3U) ^ (i >> 2U);
    }
}

Measured Execution Cycles (168 MHz Core Clock)

Key Benchmark Insights

1. With Caches & Prefetch Enabled:
   • The loop body (approx. 24 bytes) fits completely into the 128-bit ART cache line.
   • The wait-state penalty is only incurred on the first iteration (cold miss).
   • Iterations 2 through 1000 execute at zero wait states (100% cache hit rate).
   • The difference between 5 WS and 7 WS across the entire 1000-iteration run is only 12 clock cycles (0.3%)!
2. With Caches Disabled (Raw Flash Access):
   • Every single instruction fetch and branch target incurs the full $(N+1)$ cycle penalty.
   • Adding 1 wait state adds exactly $\approx 3,000\text{ cycles}$ to the 1000-iteration loop ($\approx 3\text{ cycles per loop iteration}$).
   • Conclusion: Enabling Instruction Cache and Prefetch yields a 400%+ performance boost, rendering wait state fine-tuning negligible for cached loops.

Cortex-M7 L1 Caches vs. Flash Wait States

On high-performance Cortex-M7 microcontrollers (such as the STM32F767 @ 216 MHz or STM32H743 @ 480 MHz), the memory subsystem architecture differs significantly. Cortex-M7 features built-in Harvard L1 Caches (typically 16 KB / 32 KB I-Cache and D-Cache) attached to the core’s 64-bit AXI bus.

CoreMark Benchmark Comparison (STM32F767 @ 216 MHz, 7 WS Datasheet Spec)

+-------------------------+     +--------------------+     +--------------------+
| 1. L1 Caches (I/D-Cache)| ==> | 2. Prefetch Buffer | ==> | 3. Wait State Gain |
|    (300%+ Throughput)   |     |    (Sequential 0WS)|     |    (1-3% Marginal) |
+-------------------------+     +--------------------+     +--------------------+

Safety-Critical Design Considerations (WCET, TCM, and ECC)

In high-integrity embedded systems (automotive engine control, fly-by-wire avionics, medical robotics), average throughput is subordinate to deterministic Worst-Case Execution Time (WCET).

+-------------------------------------------------------------------------------+
|            Execution Determinism: Flash vs. Tightly Coupled Memory            |
+---------------------------------------+---------------------------------------+
| FLASH EXECUTION (Throughput Oriented) | TCM EXECUTION (Hard Real-Time Safety) |
+---------------------------------------+---------------------------------------+
|                                       |                                       |
|   Flash Memory Array (5 Wait States)  |   ITCM / DTCM (0 Wait States, 64-bit) |
|         |                   |         |                 |                     |
|         v                   v         |                 v                     |
|   [ Cache Hit ]       [ Cache Miss ]  |        [ Direct Bus Access ]          |
|     (1 Cycle)           (6 Cycles)    |              (1 Cycle)                |
|         |                   |         |                 |                     |
|         +---------+---------+         |                 |                     |
|                   |                   |                 |                     |
|                   v                   |                 v                     |
|         Execution Time Jitter         |     100% Deterministic WCET           |
|       (Variable WCET Analysis)        |    (Zero Jitter / Hard Bounds)        |
|                                       |                                       |
+---------------------------------------+---------------------------------------+

1. WCET and Cache Jitter

While caches maximize average benchmark scores (e.g., CoreMark), they introduce execution timing jitter. A critical interrupt handler executing when an unexpected cache line eviction occurs will incur the full $(N+1)$ wait state miss penalty.

2. Tightly Coupled Memory (TCM) as the Safety Solution

For hard real-time tasks, Cortex-M4/M7/M33 devices provide ITCM (Instruction Tightly Coupled Memory) and DTCM (Data Tightly Coupled Memory):

• Mapped directly to the core’s internal 64-bit pipeline bus.
• Operates at true zero wait states (1 cycle access) at maximum core frequency (e.g., 216 MHz or 480 MHz).
• Immune to flash wait states and cache line evictions.

/* Direct critical ISR or safety monitor function to ITCM */
__attribute__((section(".itcm_text"), noinline))
void Safety_Critical_Fast_Loop(void) {
    /* Guaranteed 0 WS execution with zero cache miss jitter */
    Motor_Current_Regulator_Update();
}

3. Flash ECC (Error Correction Code) and Bus Faults

Safety microcontrollers (STM32H7, TI TMS570 Hercules, NXP S32K3) incorporate hardware ECC (e.g., 64-bit data + 8-bit ECC parity). If flash wait states are set aggressively out-of-spec, marginal sense amplifier timings can cause transient bit errors:

• Single-Bit Errors: Automatically corrected by hardware ECC logic, but increment an error counter and potentially trigger an ECC interrupt.
• Double-Bit Errors: Cannot be corrected; triggers an immediate hardware NMI or non-maskable HardFault, forcing a system safe-state shutdown.

Practical Engineering Checklist

Follow this systematic checklist when designing and configuring flash subsystems:

1. Datasheet Compliance: Always configure wait states based on the device datasheet’s worst-case voltage range and maximum temperature envelope. Never overclock flash latency.
2. Strict Sequencing:
   • When clocking UP: Set higher Flash wait states $\rightarrow$ Switch PLL clock.
   • When clocking DOWN: Switch lower clock $\rightarrow$ Set lower Flash wait states.
3. Enable Accelerators: Enable Instruction Cache, Data Cache, and Prefetch buffer during boot initialization.
4. Cache Maintenance on IAP / Bootloaders: If your application writes new code to flash (In-Application Programming), you must invalidate the I-Cache (SCB_InvalidateICache()) and reset the ART cache before jumping to the new code.
5. Relocate Hard Real-Time Loops to TCM/SRAM: Map motor control loops, high-speed DSP filters, and critical ISRs to zero-wait-state ITCM or internal SRAM to eliminate flash wait state penalties and cache jitter.

Related Reading

• ARM Cortex-M NVIC Interrupt Latency Optimization
• Reducing ARM Cortex-M Interrupt Latency with Tail Chaining
• Zero-Copy DMA Patterns on ARM Cortex-M
• Clock Tree and PLL Configuration in Embedded Systems
• Cortex-M SysTick Timer Configuration and Usage
• Debugging Hard Faults on ARM Cortex-M: A Systematic Approach
• Cortex-M Fault Handlers and Exception Handling in Embedded C
• Memory Protection Unit (MPU) in Embedded Systems

References

1. ARM Ltd., ARM Cortex-M4 Processor Technical Reference Manual, ARM DDI 0439D.
2. ARM Ltd., ARM Cortex-M7 Processor Technical Reference Manual, ARM DDI 0489F.
3. STMicroelectronics, STM32F405/415, STM32F407/417, STM32F427/437, STM32F429/439 Reference Manual, RM0090 Rev 19, Section 3 “Embedded Flash Memory Interface”.
4. STMicroelectronics, STM32F7 Series Reference Manual, RM0410 Rev 4, Section 3 “Adaptive Real-Time Memory Accelerator (ART Accelerator)“.
5. International Electrotechnical Commission, IEC 61508-3: Functional safety of electrical/electronic/programmable electronic safety-related systems - Software requirements.
6. International Organization for Standardization, ISO 26262-5:2018: Road vehicles - Functional safety - Part 5: Product development at the hardware level.