Does the Internal Flash have ECC protection?

[williamely]

Does anyone know if the internal flash on the Kinetis K64 has ECC or some other form of error correction or detection?

[williamely]

Thanks mjbcswitzerland​ and sergeisharonov​. The main reason I'm asking about ECC is I have an application that must endure an average temperature of 63C for a period of 25 years and I need to make sure that the MCU will retain the application for that long. The application never writes to the flash memory and runs entirely in SRAM so I think it will work under those conditions. 

[mjbcswitzerland]

William

In that case I think that the specification that you are interested in is:

If just programming the code once tnvmretpk1 Min. gives 20 years, which I believe is over the temperature range up to 125°C (Tj).

You may need to contact your sales representative to get extrapolated values for your average temperature to ensure that it is >= 25 years miniumum.

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support  / µTasker Kinetis TWR-K64F120M support  / µTasker Kinetis TWR-K65F180M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[sergeisharonov · Accepted solution]

I do not believe it has anything of the sort. MCUs' internal flash is usually NOR and NOR is supposed to be defect free (unlike NAND). Thus there is no need for error detection and/or correction. I did read user manual when implementing K22 (not K64) internal flash programming and have not noticed anything to make me think it has CRC or ECC. You can implement it yourself if you expect to take internal flash close to its wear limit. K22 even has hardware CRC engine. ECC would be software.

Regards,

Sergei

[williamely]

Thanks, I didn't know that the internal flash was NOR.

[mjbcswitzerland]

Hi

I don't know the internal Flash's details but ECC (with correction) is often used in such Flash because it allow smaller structures (and hence larger memory sizes) to be achieved, whereby smaller structures also result in some loss of reliability that can be compensated for by adding the ECC.

As reference, see the following description of NXP's Flash: LCP2378 FLASH + Demo put on-line which has been used in the LPC series for the last 10 years. It uses ECC for each 16 byte line of Flash.

The Kinetis Flash uses long word or phrase (8 byte) writes and it is possible (or even probable) that there is some ECC involved, which can be seen by trying the following on a part with phrase programmin (eg. K64), whereby the rule is that a phrase can only be programmed when it is originally deleted (all bytes in the phrase at 0xff):

1. Program a phrase with a pattern, eg. 0x00, 0x01, 0x02, 0x03, 0x04, 0x07, 0x06, 0x07

2. Now program the same phrase with a patter which changes bits from '1' to '0' - eg. the last byte in it to 0x00.

The result is often that any subsequent read access to the phrase results in a hard fault, which can only be recovered by a chip erase.

Doing the same on an NXP LPC series device results in the line of Flash being read but with seemingly random values in the line being corrupted. The reason being that the first line write also set additional ECC bits (in flash that is not 'visible' to the user). The second write results in values in the Flash being changed, as well as an attempted write the ECC which usually results in the ECC being wrong (since it can also only change bits from '1' to '0'). When bytes in the line are read back the ECC tries to correct bits and so the values read tends to get all distorted.

In the case of the Kinetis it may be that the ECC is identifying that the Flash is "corrupted" and blocking reads with a hard fault.

This is speculation due to the fact that there are no details made available but is plausible based on the fact that the basic technique is well known - check also TI's Flash in their Tivia Corex-M4 range since they publish details about their Flash using ECC to increase its reliability.

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support  / µTasker Kinetis TWR-K64F120M support  / µTasker Kinetis TWR-K65F180M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[sergeisharonov]

You are not allowed to program the same memory location (4 or 8 byte phrase in Kinetis lingo) more then once without erasing it. Supposedly over-stresses flash by keeping it under high voltage for too long. You could do that with old NOR chips but not with Kinetis. I recall there was a thread on the net where a debugger (supplied with KDS of all things!) was doing that and Freescale said it was not a good thing.

Therefor I have not tried your experiment with writing patterns and locking chip up. However I suspect that violating spec may have something to do with it ;-)

Other point is that ECC is very wasteful for short byte sequences so I doubt they would do it for a 4-byte phrases and waste silicon. Maybe somebody from Freescale can clarify?

Regards,

Sergei

[mjbcswitzerland]

Hi Sergei

In fact I never did the quoted test myself but did see the behavior. Since I work as a consultant to many Kinetis projects I have the opportunity to debug such cases and usually it occurs as a result of incorrect code rather than it being actually done deliberately.

In some cases I have also seen tools being used writing to Flash areas more than once too - including IAR's debugger - and thus turning out to be the root cause of some difficulties.

I never saw damaged flash, so some experimentation with doing illegal things won't destroy the chips (immediately). Of course, it should be avoided on production boards (restricted to those used for development/debugging) because there may indeed be long-term implications.

The TI Tiva Flash supports long word programming (4 byte phrase) and I was told by TI that the Flash does indeed use ECC (I can't find any written documentation on this though and can't verify the accuracy of the source). The NXP LPC has been using ECC over 16 byte phrases for over ten years (if I remember correctly there are about three hidden Flash bytes per 16 bytes of visible Flash). But I have no idea about the Kinetis Flash - it is pure speculation that it may well be using this (quite common) technique to be able to reduce the struture sizes and so increase the overal density/size but retain long term data retention goals. It is also pure speculation that the hard fault on a Flash phase (or possible on two flash phases) after an illegal use is due to this.

Only Freescale knows and may or may not give public details.

For us developers and users it is not that important to know how it is implemented as long as we respect the rules; then we can consider the Flash to obtain the reliability and long term data storage quoted in the data sheets.

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support  / µTasker Kinetis TWR-K64F120M support  / µTasker Kinetis TWR-K65F180M support

For the complete "out-of-the-box" Kinetis experience and faster time to market