STM32 gotchas
99. FLASH is 0xFF but cannot be written (if there's ECC and granule has been already written)

For sake of simplicity, in this text we will assume that erased state of FLASH is all-ones, ie. all bytes are 0xFF. This is not the case for 'L0 and 'L1 as has been described in Gotcha 98. As 'L0 does have ECC, the issue itself still pertains to this family, too.

Newer STM32 families are built using technologies with extremely small features, benefiting from the respectively increased circuit density. However, smaller transistors in FLASH also means a smaller volume of the floating gate where the charge representing programmed value of given bit is trapped, hence it means increased probability that noise during readout causes an incorrectly read bit.

To mitigate this problem, FLASH in these families is equipped with error detection and correction circuitry (ECC). FLASH is divided into granules (smallest portions which can be written, 32, 64 or 128 bits, depending on particular STM32 model). These granules are augmented by additional FLASH bits, invisible to the user, into which the error-check code is written, when the granule itself is written.

When the FLASH is read - regardless of whether code to be run is read from it, or data - the FLASH controller always reads the whole granule, performs the ECC check, if there is a single bit error, corrects it, and then returns to the system the requested portion of the granule.

If two or more bit error occurs, the error is uncorrectable. What happens in this case depends on the particular STM32 family/model. In most families, the uncorrectable error causes an NMI (nonmaskable interrupt), and then it's up to the user how this error is handled. In most families, also the single-bit error may throw a particular interrupt, if enabled.

There are several consequences of ECC on FLASH, which may be surprising to unaware users:


STM32 families can be roughly divided into the following groups, as far as their FLASH is concerned: