AnsweredAssumed Answered

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

Question asked by Mark Bereit on Oct 20, 2015
Latest reply on Oct 29, 2015 by Jorge_Gonzalez

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!

Outcomes