File corruption when device powers down while writting to NAND Flash

[jamesnguyen]

Hi,

When our device is powered off while writing to a NAND flash, the firmware in the NAND Flash is corrupted and prevents the device from ever powering up again. Is there any application note or tips to fix this problem?

Thank you in advance!
James

 

[MacGyverS2000]

Yeah... don't power down while writing to Flash. On the obverse, don't write to Flash while powering down. Seems pretty obvious.

If you can't guarantee both conditions happen only when you want them to, it's up to you to take that into account. Implement CRCs on the Flash data. Only erase a sector after the new one has been written. Provide some capacitance on the power supply and a sense line so you know when a power down sequence is happening and you should stop writing to Flash. Use battery-backed RAM rather than Flash. Use multiple Flash chips and only write to one at a time. And on and on and on...

Dan - Owner

http://www.Hi-TecDesigns.com

 

[IRstuff]

Isn't that why most systems, when writing modifications to critical systems, say, "DO NOT turn off power during this operation?"

If your user is that moronic, then you need to design your system to keep him from being such an idiot, so as Dan says, implement some sort of uninterruptible power, or simply interlock the power system until the flash is done with programming.

TTFN

FAQ731-376
Chinese prisoner wins Nobel Peace Prize

 

[VEBill]

All above advice is correct.

The following possibility may not apply to "firmware" (as opposed to data, it depends on your exact application), but a 'Journaling File System' (*) can be significantly more resistant to file corruption.

(* Here's a link to the Wiki explantion:

http://en.wikipedia.org/wiki/Journaling_file_system

)

 

[jamesnguyen]

Our product is a mobile device which running on a battery pack.

There is no way for us to prevent user from removing the battery at any given time.

Even if we displays "DO NOT turn off power" and user remove the battery pack anyway, then what?

I like some ideas Dan proposes.
James

 

[itsmoked]

Dan's ideas are the pretty much the standard methods. If you have to erase some area before writing it and the power is expected to leave at anytime. Then you need to provide enough space in the flash space to keep a copy of the area erased. You need to also keep at least a checksum in each block. When power up occurs you checksum the blocks. If the last one was toasted you use the prior one.

Keith Cress
kcress -

http://www.flaminsystems.com

 

[IRstuff]

Directly writing over working firmware is almost always a bad idea anyway. You could have cells that die along the way, and your code would become Tango Uniform.

As in the case of the Windows configuration files, you could have a simple ping-pong configuration, so that only when a firmware load is fully written and VERIFIED, do you switch over to the new load. You would also have a flag to indicate that a burn was in progress, so that the existing firmware can check to see if the new load was completed, verify it, and the switch over, if the operation was interrupted. If your flash is written to very often, it behooves you to make provisions for multiple copies of firmware in memory, and be able to switch between them, just as Windows allows you to select, "Last known working configuration." You might even want to include a boot option that allows the user to select a firmware version to boot up.

As mentioned by others, these measures are all extremely standard, and I've product specs that explicitly require this type of protection.

TTFN

FAQ731-376
Chinese prisoner wins Nobel Peace Prize

 

[VEBill]

One approach is to segregate the "boot code" from the rest of the system firmware. The boot code also manages the firmware update process. So even if the firmware is corrupted, the rigorously-protected boot code can be invoked to reload the firmware again.

Updating the boot code itself (hopefully very rare) becomes the only 'white knuckle' time.

..

Once upon a time there was an HF radio transceiver made in Japan by one of the well known manufacturers on such things. The radio's OS was loaded in RAM (!) with a little lithium cell to keep it up. When battery got old, it had to be replaced while another battery was temporarily connected in parallel to (hopefully) hold up the RAM. One false move and the radio went back to the service center for a fresh battery and a reloading of the OS into the RAM.