Changes to the FlashX driver between MQX 3.8 and 4.1

[Gra]

A while back I wrote some software that ran on a Kinetis K60 using IAR 6.4 and MQX 3.8. The software used the FlashX driver to erase and then write non contiguous single bytes to a section of flash between 0x60000 and 0x7FFFF (128KB).

We now have new hardware that uses a K70  (MK70FN1M0VMJ15) I'm trying to recreate the project using IAR 6.5 and MQX 4.1.

It erases all the sectors between 0xC0000 and 0xFFFFF (128KB) correctly,but it will only write to the first byte at 0xC0000, further writes to 0xC0002 and 0xC0004 fail.

The code is based on the FlashX example include with MQX, which doesn’t appear to have changed much between versions. The driver seems to have changed quite a lot though.

All caching is disabled and I’m not overwriting bytes.

Is anyone else having similar issues or could help?

Many Thanks

Graeme

[Gra]

Mark, thank you so much for all your help! (also thank you David! I read all these app notes this morning, but it's good to hear from someone else that backs the facts up :smileyhappy:)

After reading your last response Mark, I trawled through loads of documents re the K60 and K70 flash and I’m now totally convinced the minimum write to flash on a K70 is 8 bytes. I’ve just tried writing 1 byte every 8 bytes on my K70 and it works, anything less and it fails.

I did consider only storing 1 byte per 8 to give the illusion it was byte writable, but I require 128KB so that would be all my flash gone!

I am still very confused re my K60 project though. I totally agree there may be a RAM layer there, but I purposely turned off all RAM caching so it wasn’t tricking me. To try to prove that RAM was not involved I’ve just performed a test on the K60 that involved 3 builds of software. The first build just erased a portion FLASH, the second build just wrote 1 byte to even addresses and the third just wrote 1 byte to odd addresses. I ran each build in turn, powering down between each and the read the flash at each stage using my j-link. The final read showed all bytes had been written to and there were no errors. Bit of a mystery! I wonder if the MQX 3.8 FlashX driver is incorrectly letting me over-write the 4 byte chunks?

Regards

Graeme

[mjbcswitzerland]

Graeme

You have made a good set of tests.

It may be possible to write multiple times to a long word (typically it is recommended to write the bits that have already been programmed to '0' as '1' to reduce the strain on the device since it would otherwise 'overprogram' the bit), such as the Freescale Coldfire's internal flash. The internal Flash in the Kinetis however doesn't expressly allow this and the user's manual advices against it (or forbids it) - it is therefore to be treated as an error in the usage (although may still work). If it may work on the K60 doesn't mean that it may work on the K70 (or other types of existing or future Kinetis parts) since the K70 uses phrases and not long word writes - therefore 'generally' I would consider any code that tries to make use of an (illegal) possibility of one type to be "non-portable" and so generically incorrect, as well as risking potential damage or reduction in reliability.

For flash programming I use the uTasker uFileSystem or uParameter system which adds a small phrase buffer (called a row buffer for generality) to collect bytes that the user wants to program. Only when a "row" has been filled is the write actually performed. This allows application code to write a buffer to Flash by simply passing the buffer as a byte array - at the end there may be some bytes still in the "row" buffer waiting to be committed and the user can then expressly commit these if needed, but being aware that the end of the buffer write may not be aligned to a "row" and so the final bytes in Flash are still 0xff and can not be written (these aligning details are mainly handled in the uFileSystem or uParameterSystem layers).

I don't know the internal workings for the phrases but one should not forget that modern Flash is often using some form of ECC (this increases its reliability by adding invisible ECC values to each phrase that allow bit errors (due to bad flash or age) to be corrected - sometimes there is more physical Flash available than the user sees since the ECC bits need to be stored too). One side effect of this is that if the ECC is saved when only writing a part of the phrase its value initially matches the phrase content - if then another byte in the same written phrase is re-written the phrase's ECC will change but won't be able to be written if it involves bit changes from '0' to '1', although the physical write of the phrase's content was possible. The result is that when the value is read back from flash the flash's ECC finds an ECC error and tries to correct it, resuling in the value read from Flash to be (incorrectly) modified. This is another reason why additional restrictions may exist between different Flash types even if it physically possible to perform multiple writes to the individual phrases.

Some manufacturers (almost secretly) add this feature to the Flash between silicon revisions and then Flash drivers that are not respecting the rules suddenly fail (eg. ATMEL did it on their AT91SAM series, which also required the user to add 2 wait states to each FLASH memory read!!!). The NXP LPC range have used 16 byte phrases in their Flash for the last 10 years - one of the most interesting forum posts that I have ever read is from an NXP application engineer explaining some of the details to users who otherwise had no idea that it existed and were trying to work out the strange side-effects that could result: the details are sumarised at LCP2378 FLASH + Demo put on-line where the original link can also be found (it looks like the original forum has moved to private mode recently so requires memembershup to actually read the original).

Note that I am not suggesting that the K70 phrases has ECC - the topic is just general and illustrates the importance of respecting the manufacturer's rules and guidelines

Regards

Mark

[mjbcswitzerland]

Hi

The K60 writes long words to Flash and the K70F writes phases (8 bytes).

Possibly your missing a setting to inform the code to use phrase and not long word programming (which won't work on the K70F)?

Regards

Mark

[Gra]

Thanks Mark

Are you saying you can only write a minimum 4 bytes to the K60 and 8 bytes to the K70? That is certainly the impression I got when initially developing on the K60 with Freescale's bare metal drivers, as I had to write in blocks of 4. However the FlashX driver on the K60 let me write individual bytes wherever I wanted.

Regards

Graeme

[DavidS · Accepted solution]

Good reference material:
AN4835 - Production Flash Programming Best Practices for Kinetis K- and L-series MCUs
AN4695 - Avoiding Read While Write Errors When Developing In-Software Flash Programming Applications for Kinetis and ColdFire+ MCUs

Good resource for searching for technical documents the we/FSL are good at hiding:
http://www.freescale.com/infocenter/index.jsp

Regards,
David

PS The info Mark has given is good and helpful too.  Thank you Mark!

[mjbcswitzerland]

Graeme

I don't know the FlashX driver but if you are working in Flash program memory or in NVM in data mode it is not possible to physically write smaller entities than the 4 or 8 bytes. It is possible to write a single byte of these to a non 0xff value but a second write to the same location would later not be possible without first erasing the sector.

FlashX, as other such SW layers, probably adds a RAM layer between which emulates the storage space and so allows writing single bytes and commits them only when the smallest entity has been filled.

Another method is to write each byte to a single smallest entity (reducing the total number of storage locations) but making it look like it is a byte-write interface.

In both cases, if the driver didn't have the correct setting (smallest entity size and write command to use) it would fail so it is one thing that you could probably check quite easily to rule it out if necessary.

Regards

Mark