K22 FLASH, Question about (re) writing to a longword

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

K22 FLASH, Question about (re) writing to a longword

989 Views
chriskeeser
Contributor III

I am attempting to write an easier-to-work-with flash utility and I want to be as efficient as possible when an erase needs to occur (due to how long it takes).  I am curious about the following situations:

Situation: The flash sector is previously erased, and a single byte was written into a longword.  The other 3 bytes are still erased, and the longword looks like this:  (erased) 0xFF 0xFF 0xFF 0xFF -> (programmed) 0x01 0xFF 0xFF 0xFF


Q1.) If I wanted to program the second byte to 0x02, resulting in 0x01 0x02 0xFF 0xFF, can I program the longword with 0x01 0x02 0xFF 0xFF, or do I have to erase the entire sector to write that single new byte into an already erased byte?


Q2.) If reprogramming the 0x01 in the first byte will overstress the device (which I have seen warnings that say writing a '0' multiple times will overstress the FLASH) then, can I be cheeky and attempt to program 0xFF 0x02 0xFF 0xFF into the already programmed long word?  The first byte would be "programmed" to 0xFF (which means that no zeros would be re-programmed), or will this result in some sort of fault (either during programming, or attempting to read the flash)?

Thanks, and Looking forward to hearing the answers!

0 Kudos
7 Replies

774 Views
egoodii
Senior Contributor III

The reference manual states that you must write a longword whole as one step, and leave it alone from there.  You can expect this has a 'little' to do with overstress, but the larger issue is hidden ECC bits written with a longword-write which CANNOT be updated as part of a 'further write'.  Access after the 'second write' will net a hard-fault.

0 Kudos

774 Views
chriskeeser
Contributor III

Thanks for the prompt reply!  I wonder then, what happens if I "program" a longword with 0xFF 0xFF 0xFF 0xFF, then later "re-program" it with new data?  What I am concerned about is, how will I know if a longword has been programmed before if I can't simply check to see if it is 0xFF 0xFF 0xFF 0xFF?

0 Kudos

774 Views
egoodii
Senior Contributor III

I suppose it is POSSIBLE that the ECC written with an 'all ones' datablock would ALSO be 'all ones', so that the result is still a 'virgin longword' --- I suppose you can try writing that, then something else, and see what happens on the readback!  Makes me ask though why an 'optimized algorithm' would even TRY to write a longword that matches 'what is already there'...

0 Kudos

774 Views
chriskeeser
Contributor III

The question is valid considering that flash could be "programmed" to 0xFF by a less-than-efficient programmer or bootloader that I have no control over.  My question on "programming" a long word with 0xFF's was meant to suss out the deeper details.

0 Kudos

774 Views
egoodii
Senior Contributor III

Freescale/NXP is intentionally 'tight lipped' about even the EXISTENCE of this unseen ECC, let alone willing to discuss ANYTHING about it.  Tools that use this memory as 'proper' program-flash are going to be cleanly erasing and writing 'whole chunks'.  It is only us tricksters trying to do things like place 'some rarely updated' parameter-sections in this flash that have to be 'more careful' in usage

0 Kudos

773 Views
chriskeeser
Contributor III

Thanks for the insight Earl.  I did stumble across some post during my searches that discussed this hidden ECC.  I'll just stick to erasing the whole sector if any byte in the long word is not 0xFF.

0 Kudos

773 Views
mjbcswitzerland
Specialist V

Chris

It may make sense to do a comparison of the long word being programmed with the long word that is already in the Flash:
if (*(unsigned long *)addressToProgram == ulLongWordToProgram) {

    return; // skip programming since it already matches

}

else {

    // program it

}

The check is very fast and each time it matches (when 0xffffffff is in the data stream  to be written) it saves 50us or so of programming time (maybe making overall programming of data streams faster overall)

The side effect is that you can be absolutely sure than a long word with 0xffffffff has never been programed before, avoiding any worries about whether programming all ones stresses the Flash in any way or not.

Regards

Mark

Professional support for Kinetis: http://www.utasker.com/index.html
Remote desktop one-on-one coaching: http://www.utasker.com/services.html
Getting started to expert videos: https://www.youtube.com/results?search_query=utasker+shorts

0 Kudos