QE128 Flash problem

[tonyp]

Hi all,

Some QE128-based device came back for maintenance after having spent about 5 years in the field running 24/7, and I noticed it would no longer save its configuration into its internal Flash.  Flash rewrites are not very common with this device since parameters change very rarely, if ever.  (The MCU is in a high-power RF area.)

I thought there might be some Flash corruption that affected code execution, so I loaded new firmware but the problem remained.  After some BDM debugging, I noticed the following:

The flash could not be erased & re-programmed unless I repeat the erase process twice (regardless if I program in between), with no significant delay in between the trials.  So, erase-erase-program or erase-program-erase-program both work.  If there is any delay (like a second or more), there is failure.  So, I ended up patching the firmware to call the configuration save routine twice, and this bypassed the problem for now.

But, I'd like to know why this happens.  I can understand Flash may be starting to fail and it's becoming harder to erase/program (e.g., needing more time for the erase), but the Flash erasing process returns without errors, even when it fails to erase.  So, how am I to know the process failed (without actually verifying each and every byte for being $FF)?  If there were an error, at least it could keep trying (say, to erase) again and again for a predefined maximum number of times, before declaring the Flash unusable.

By the way, Flash clock (FDIV) is set around the high end, 200KHz.  Would a value closer to low end (150KHz) have better results over long time?

[pavel_sadek]

Hi,

there is errata for flashing QE128 - take a look into

SE133-FLASH: Unexpected Flash Block Protection Errors

this is also in conformity with your statement of dual erase.

http://cache.freescale.com/files/microcontrollers/doc/errata/MSE9S08QE128_0M11J.pdf?fpsp=1&WT_TYPE=E...

hope this helps

Pavel

[kef2]

Tony, did you try to confirm that PRDIV8 and FDIV fields in FCDIV are set up correctly? Unless you write 1 to FDIVLD bit first, this piece of code

FCDIV_FDIV=xx;

FCDIV_PRDIV8 = y;

makes first (FDIV) assignment granted by MCU but second (PRDIV8) assignment ignored.  FCDIV is write once register, unless you keep writing 1 to FDIVLD.

[tonyp]

Thanks for your suggestion.  FCDIV is written with a single instruction which combines the values for the two fields, so no possibility of this happening.

I only write FCDIV once (the first time) decided by the current state of the DIVLD bit.  Although now I realize this checking seems redundant because you can always refresh the register for those MCUs where multiple writes are allowed, while for the rest, the extra write is simply ignored.

After re-reading the docs (after many years because my library routines were considered stable), I guess there is no error indication for the case the command is not completed successfully, only for setup errors (FPVIOL, FACCERR).  So, a successful completion of a Flash command does not mean success, only potential success.

So, we just need to hope that the internal timing for the ERASE/PROGRAM commands (timing for which we can't do much, other than lower the clock to prolong a bit the overall duration) is sufficient even as the chip ages.  I'll try to lower the frequency to 150KHz and see if that completes the erase in a single operation (instead of the workaround for two consecutive ones).  But even if this works for now, it's still a matter of time as the chip ages a bit more until eventually the command built-in duration will be slightly shorter than needed, again requiring double (or more) repetitions to get the total time to be enough.

Which means, the way I now understand it, the only real solution for knowing if a Flash command succeeded is to add code to verify each erase and program operation and, if the expected result isn't found, repeat the process, for up to a maximum number of times.

Additional comments / suggestions are welcome.