What are the rules for random writes to Flash? (K64)

[markbereit]

In a set of code I'm porting onto Kinetis for the first time, we used Flash storage for a non-volatile registry.  This code relied upon the convenient rule that you can always change a "1" bit to a "0," but not go the other way without erasing, so we got good efficiency out of, for example, changing an identifier byte to 0x00 to mark it as deleted.  This sort of thing failed totally on Kinetis.  Frequently--not always--the attempt to rewrite a byte would make the byte location unreadable.  Incredibly to me, this unreadable byte condition would persist through a power cycle: a normal processor read to the location would trigger an unhandled interrupt.  (Erasing the offending sector was the only way to get the memory back to readable.)  After some digging, I saw this in the K64 data sheet:

A Flash memory location must be in the erased state before being programmed. Cumulative programming of bits (back-to- back program operations without an intervening erase) within a Flash memory location is not allowed. Re-programming of existing 0s to 0 is not allowed as this overstresses the device.

That seemed to clinch it: the K64 Flash doesn't allow a byte to be changed to a new value, even if (old_value & new_value) == new_value.

On that basis, I started revising all the code to do the same job with more bytes--less efficient to dedicate bytes for flags, but not hideous.  But, I also did further tests of manually performing byte writes out of order, and I still can lock up a memory location!  Given a sequence of operations such as this...

• Flash a byte value to address 0x70003
• read bytes 0x70000-0x7000F
• Flash a byte value to address 0x70001
• read bytes 0x70000-0x7000F

...sometimes this sequence is enough to lock up the ability to perform the second read sequence.  I did NOT attempt to reprogram a byte, but I still broke it.

For my Flash operations, I am using the code generated by Processor Expert (in the current KDS, although in this instance my project is not using the KSDK), calling Flash1_Init, Flash1_Write, Flash1_Main, etc.  I'm using simple pointer operations for the reads.

From digging into the Flash1_Main code, I can see that the actual Flash operation is happening on "phrases" (sequences of eight bytes), but that PE-generated code is also going to pains to accept updates to bytes within the phrase that are still 0xFF even if the whole phrase is not, so I would expect that I can freely write any byte that is currently 0xFF.  However, I have seen this fail, so I don't know what rule I can trust.  Do I really need to only Flash an untouched phrase?  (That is, use eight bits for every state flag I need?)

Looking for some explanation of when it is safe to program into unused Program Flash, since I can't find an explanation that fits what I'm seeing.  Anyone?  Thanks!

[Jorge_Gonzalez · Accepted solution]

Hello Mark Bereit:

The K64 has a FTFE type flash memory module. The smallest programming size as you pointed out is a phrase (8 bytes). It is not allowed to overwrite the same phrase without a previous erase. Please see the next discussions in the community about the same:

FTFL FTFE Flash controller behaviour

Kinetis K10FX512 read flash hard fault

I hope this clarifies your question.

Regards!

Jorge Gonzalez

[markbereit]

Jorge, thank you for your quick reply.  My search had not turned up either of the links you cited, so thank you for pointing those out.  I will adapt my code to never rewrite any phrase.

I certainly did not infer this phrase boundary restriction from the text I cited in the data sheets (and, obviously, neither did the people on those other two threads!), so I would suggest that the data sheet text for the FTFE module be updated to clarify this rule.  (How does one feed a suggestion back to the Freescale documentation team?)

And I need to point out that the Flash code generated by Processor Expert shares my reading of the data sheet, believing that it is legal to write to an erased byte within a not-fully-erased phrase (and going to the extra trouble of merging the existing content of the phrase with the requested write data).  The hard faults mentioned by me (and both threads you cited) are being allowed by the code produced by Processor Expert.  I should think that Processor Expert should be corrected as well.  Here is the relevant code from Flash1_Main:

  FlashPrgUnitAddr = DeviceDataPrv->CurrentFlashAddress - DstAddrOffset;

  CurrentFlashPrgUnitData[0] = ((uint32_t *)FlashPrgUnitAddr)[0];

  CurrentFlashPrgUnitData[1] = ((uint32_t *)FlashPrgUnitAddr)[1];

  if(((DataToPrg[0] & DataToPrgMask[0]) & (~CurrentFlashPrgUnitData[0])) > 0U) {

    DeviceDataPrv->CurrentErrorFlags |= LDD_FLASH_MULTIPLE_WRITE_ERROR;

    return;

  }

  if(((DataToPrg[1] & DataToPrgMask[1]) & (~CurrentFlashPrgUnitData[1])) > 0U) {

    DeviceDataPrv->CurrentErrorFlags |= LDD_FLASH_MULTIPLE_WRITE_ERROR;

    return;

  }

My example of having a byte written at 0x70003, then trying to flash a byte at 0x70001, breezes right through these checks.  Based upon the rule you stated, the tests should be rewritten as:

  if((~CurrentFlashPrgUnitData[0]) || (~CurrentFlashPrgUnitData[1])) {

    DeviceDataPrv->CurrentErrorFlags |= LDD_FLASH_MULTIPLE_WRITE_ERROR;

    return;

  }

That would have rejected my attempt to modify an already programmed phrase, and then the hard fault would not have occurred... and I could have answered my own question of what is legal to do on the K64 Flash!  (So, how does one feed a suggestion back to the Processor Expert team?)

Again, thank you for the prompt answer.  Now I'm just asking how to make this problem not hit the next developer!

[Jorge_Gonzalez]

Hello Mark Bereit:

Sorry for the delay and thank you for your feedback.

These issues have to be reported internally, so I will handle it. The Processor Expert code may be fixed in the way you propose for a coming version. In the case of Reference Manual this may take more time, since new revisions need to pass through a verification process.

Thanks again!

Jorge Gonzalez