Test cycles flash of KE04128 MCU

[ricardcomas]

Hi, how i can chek the maximum cycles (read/write) that it can support?? i have a code that just write and read a first byte of a zector.

But it count up to 1.000.000.000 cyles and it still work!!, it's not possible, this is my code

if(read_err == NON_ERROR){ //Si no hi ha error de verificacio...

IFsh1_SetByteFlash(TEST_SECTOR_ADDRESS+posi,dada);
contador_grav++; //Incrementem el contador
}

IFsh1_GetByteFlash(TEST_SECTOR_ADDRESS+posi,&buff);

if(buff == dada)
Mux1_BinToBcd(contador_grav,8,0);
else while(1);

[bobpaddock]

Don't overlook temperature.

It is possible an immediate write will read back correctly.
It may not read back correctly in ten minutes.

As others have pointed out, stick to what the datasheet says.

There are ways of increasing write endurance by updating things in different sectors

and using a pointer to the active sector.  The tricky part becomes handling the counter of wear and the pointer.

[ricardcomas]

Hello, first, thanks for ask me.

My code, do following:

- Write a byte value (0xAA)

- Read position where value has been saved,

- Compare read value to verify it's correct

- Save  0xAA complement 1 (it is 0x55), so the value change  from 0xAA to 0x55 and inverse again...

so value to store is always either 0xAA or 0x55

the code repeat agains forever...

But, in the flash component, there's an option called "Write Method" it's work as Destructive write method right now, so, 

when i gonna to save value in to flash, the current sector is erased automatically, isn't?

Should i change this option so that make test flash correctly?

Thanks 

[davidsherman]

Not to dispute your findings, but I'm inclined to believe that your write routine was erasing first.  If you were writing 0xAA and 0x55, your test would have failed if it did not erase first.  Given the data sheet Kerry showed, it typically takes 20mS to erase a sector, so if writing those 2 values took 2 erase cycles, it would have taken at least 462 days running continuously to get to 1 billion writes.  Did it actually take that long?

I agree with Kerry though, Freescale most likely went through similar testing on multiple parts to arrive at those published endurance figures, and your testing on one part might not be a reliable data point.

[egoodii]

Furthermore, the gentleman should be aware that while one element of 'wearout' could be defined to the point of 'cannot immediately read back' (enough electrons leaked during each tunneling action to prevent adequate read voltage), the more insidious 'wearout' affects the ability to hold proper RETENTION for read-margin in 20 years (or whatever the datasheet guarantees).

As stated elsewhere, flash-cell wearout is NOT something you can just 'test' at the user-level; it requires characterization by tools available only to the factory.

[kerryzhou]

Hi Ricard Comas,

   Before you do the flash write, you must erase the according sector at first.

   Besides, I don't know why you do this maximum cycles, it has no meaning, because even you test one chip, the other data may not like what you have test.

   What we can guarantee is the datasheet's flash endurance.

Normally, in the design, you need to refer to the min data.

Wish it helps you!

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[davidsherman]

I can't tell from your example, but what are you writing?  If you're writing the same value, you may not see a problem because flash wears out such that bits will get stuck and won't erase.  If you're writing the same value every time, it may show no problem because that value isn't changing.

A better test would be to write a changing value, confirm it, erase it, confirm that the erased sector is all 0xFF, and repeat using a new value.