Difference of writing 0xFFFFFFFFFFFFFFFF to page erase in flash?

[SSchi.4]

Hi,

After a flash page erase I can write 0xFFFFFFFFFFFFFFFF to a certain position in my desired page (see code snippet). This for sure doesn't change the content of my Flash. However if I want to write again on that very same position, a PROGERR comes up. So there must be a bit or so that describes if a position in the flash page has already been written or not (even if it is a 0xFFFFFFFFFFFFFFFF value). Where can I find that bit?

HAL_FLASH_Unlock();
  if (HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, 0x0801F000, 0xFFFFFFFFFFFFFFFF) != HAL_OK)
  {
    Error_Handler();
  }
  HAL_FLASH_Lock();
 
  HAL_FLASH_Unlock();
  if (HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, 0x0801F000, 0x1111111111111111) != HAL_OK)
  {
    Error_Handler(); // This Error_Handler() gets called, due to PROGERR
  }
  HAL_FLASH_Lock();

Kind regards

Simon

[Uwe Bonnes]

After erase, ECC is cleared. After writing the erased pattern, ECC is set to some other value and so a second write can not set the right ECC.

[SSchi.4]

Thanks for the quick response, however I cannot detect any changes in ECC for both writes. ECC remains 0x0 the whole writing process.

[Tesla DeLorean · Accepted solution]

You get ONE bite of the apple, you can't do this BIT KNOCK DOWN thing you might have used elsewhere. Only write a value to memory if it's different to the current/initial content.

The flash lines have ECC bits that aren't visible to you.

Other flash devices can be multi-level, ie not binary, so your methods/expectation might need to change/evolve.

[SSchi.4]

alright, thanks for clearification. Then I have to find a workaround

[Tesla DeLorean]

Yes its unfortunate, as it gets to be expensive. Perhaps the 64-bit write can hold other data as you journal it.

Some of the other parts have some actual EEPROM

The width comes from the methods used to overcome the inherent slowness of reliable FLASH, perhaps probably still 35ns or so, the width allows for prefetching, buffering or caching to spread the cost of access over multiple words. Basically 0-cycle, and faster than 1-cycle RAM, or adding in wait-states.

[Pavel A.]

It seems to be a well known fact that internal flash of STM32s can be written only once after erase.

Even if you write FF bytes over erased space that reads FF.

Not sure whether it is effect of internal ECC or not.

Bottom line, it isn't possible to leave a FF-filled "hole" in the binary and write to it later (unless you have a custom flash utility that deliberately skips areas of FFs).

Space from the end of firmware image to the end of erase block usually remains writable.

[Piranha]

On F2/F4/F7 and probably some other series the flash can be written as many times as necessary, but the bits are only flipping from 1 to 0.