When ECC stops protecting your data: Cortex-M7 erratum 1267980

You turn on cache ECC for one reason: so that a bit flip cannot silently change your data. This erratum breaks that promise: the error is detected, yet memory and cache end up disagreeing, and the CPU reads the cache.

The setup

The Cortex-M7 data cache has two ECC error bank registers, DEBR0 and DEBR1. When ECC finds a bad cache location, the core records it in a DEBR and stops allocating there. Software can lock a DEBR so it isn't overwritten.

The erratum

Erratum 1267980 (Category C, present in r0p1 through r1p2, still open): if both are locked and an ECC error hits a cacheable store to an address already in the cache, the store goes to the bus but not into the cache. The cache keeps stale data, with no fault and no flag. ECC saw the error and the system still ended up inconsistent.

The catch: a race between your lock and an error

If the error arrives before the second lock, it's recorded and handled. If it arrives while both are locked, you get silent stale data. Your exposure is how long both stay locked, times the ECC error rate. That makes it untestable on demand and easy to miss.

What to do

Arm's workaround: never lock both. If you inspect an error location, lock one, and keep it short.

This only applies to parts with D-cache ECC enabled. Check your vendor's startup and diagnostics code for anything that locks both.

In production, details matter: always verify behaviors against the official documentation for your specific part, core stepping, and toolchain. Silicon integrations vary widely.

Source: Arm SDEN-1068427 v11.0, Cortex-M7 software developer errata notice, erratum 1267980. Check the current revision of the notice on Arm's site.