Flash corruption problem.

All flash chips have limited write capability. Some chips actually move data around so that when you write it, you are not writing to the same spot each time. USB memory sticks have this implemented. The "disposable" digital camera sold a few years ago did this in software,

Eventually the memory becomes unuseable in spots that are written often, for example if you use a memory chip as a DOS formated file system, the FAT (file allocation tables) and master directory get written many times as you write a file.

If for another example, you are writting the value of a sample to the same spot every millisecond, the chip will become unuseable in around a minute, depending upon the chip.

Geoff.

Flash corruption can happen at times when the microcontroller is allowed to "run" when operating conditions are not within the guarenteed limits specified by the manufacturer. Under such conditions the code may not run in the intended manner and the microcontroller may execute strangly.

Of particular concern are instances wherein you actually have FLASH writing routines within the firmware code itself. If there is a glitch or upset of some sort that sends the microcontroller out to lunch these routines could be accidently invoked and cause one or more writes into the FLASH area.

This type of upset problem can also exist on microcontrollers that have on-board EEPROM memory.

Here are some things you can do to make your system less likely to encounter FLASH upset.

1) Use a precision reset supervisor / voltage monitor that is external to your microcontroller that monitors the power supply rail to the microcontroller. If the applied voltage on the rail goes outside the normal operating range for the microcontroller then force the microcontroller into hard reset. Too many of the on-board reset supervisors that manufacturers put on the microcontroller chip are not precise enough or only measure when the voltage is too low (as opposed to measuring when it is too high or too low). 2) Make sure to implement the watch dog timeout scheme in to your product so that if a voltage, current, or EMI transient occurs and upsets your microcontroller code flow that you have some chance of recovering from it. The longer an errant program runs the more likely it is to accidently run into those resident flash writing routines. 3) Setup your calibration data base in the FLASH with two copies, each with a robust CRC type check code attached. Then design your system so it has a chance to run even if one copy of the calibration data is corrupted. 4) Setup the micocontroller with an additional I/O pin or two that must be asserted to certain logic levels to enable the FLASH write calibration process. At other normal operational times put these I/Os onto an alternate idle state via pullup or pulldown resistors. Then right inside the lowest level subroutines that perform the FLASH write operations on a byte by byte basis qualify the process every time on the enable assert levels being present on these additional I/O lines. Errant code execution is now less likely to be able to enter the FLASH write routine and do any damage as the the routine will kick out if the I/Os are not at the correct state.

- mkaras

Is the corruption occurring during write cycles, or does it happen after the device is written to?

Have you checked the errata listing for this device?

This is referred to as "wear leveling"

Of course, if you have a application that writes to a memory location that often, you should be using SRAM or DRAM. The device the OP is using has a minimum life expectancy of 10K write/erase cycles. That being said, most modern flash memory devices are good for 100K write cycles or more.