STM32F746 — transient single-bit ITCM Flash read errors after multi-hour soak (X-CUBE-STL Flash TM)
MCU / setup
- STM32F746IGK, VDD = 3.3 V
- HSE 16 MHz, PLL: M=8, N=200, P=/2 → SYSCLK = 200 MHz (AHB=200, APB1=/4, APB2=/2)
- Scale 1 + Over-drive,
FLASH_LATENCY_6 - Already below the 216 MHz maximum
- Application executes from the ITCM Flash alias (
0x002xxxxx; AXI alias0x080xxxxx) - Cortex I-Cache and D-Cache disabled at startup
- ART accelerator / prefetch enabled in HAL (
ART_ACCELERATOR_ENABLE,PREFETCH_ENABLE) - Bare metal, 1 ms cyclic scheduler, no RTOS
- X-CUBE-STL Flash TM every 1 ms: 1 KB window, HW CRC-32 (poly
0x04C11DB7, init0xFFFFFFFF, word reverse in / reverse out). Expected CRC is a table built offline from the same image (zlib.crc32/ IEEE 802.3).
What we see After several hours in RUN (typically ~11–19 h, not at POST), Flash TM returns STL_FAILED (0xD32D) on a 1 KB window. A software CRC of the same window also mismatches, so this is not only the CRC peripheral.
On fail we dumped the 1 KB window from the CPU. The dump CRC always equals the TM computed CRC and differs from the programmed image by exactly one bit. That bit is sticky for that MCU during the fail burst (every complete dump shows the same address/bit), but a later TM retry on the same window often passes — so this is a transient read, not a cell that stayed programmed wrong.
Two different devices, two different locations:
| Device | ITCM / AXI byte | Programmed | Read | XOR |
|---|---|---|---|---|
| A |
|
|
|
|
| B |
|
|
|
|
So it is not one software bug at a fixed section. The failing window moves with the image layout and with the part.
What we already tried
- A +152-byte
.textchange (no STL change) was the first-bad layout on one bisect; padding that 152 bytes back made a 24 h soak pass. That only changes which 1 KB the CPU TM code sits in, not the TM algorithm. - Running the Flash data read through the AXI alias (
0x080xxxxx) delayed the fail but did not remove it. - I/D-Cache were already off. A 1-bit error in 1 KB is not an ART 16-byte line being replaced as a whole.
- Clock is already derated (200 vs 216). Further downclock is not an acceptable product fix.
- Double-read / retry: we did this; the second TM pass often succeeds. That masks the event, it does not explain a per-die sticky bit.
Questions for ST
- Is a transient single-bit error on the ITCM Flash data-read path a known STM32F746 issue at 200 MHz Scale 1 + Over-drive, WS=6?
- Why would the failing bit be per-device and sticky for hours of dumps, yet a later CRC of the same window pass?
- Is the recommended workaround only lower fCPU / disable ART during TM / software vote? Those do not look like a root-cause fix for a production part that must run from ITCM.
- What register dump or FA data do you need (Flash ACR, PWR, VCAP, temperature, the two bit addresses above) to open an analysis?
