FAT Corruption in WinCE Device(NOR FLash)
Manish posted on Thursday, April 29, 2010 10:51 AM
Hi ! We have developed an application on WincE enabled device (i.e. MOXA UC-7420), the same has been deployed in the filed . Now we are facing a big problem of FAT corruption (We can see some garbage charactor in the folder , or all the files/folders are disappeared) . When we asked this to the MOXA company ,they said this is a problem with WinCE FAT system. The only solution is to reformat the NOR Falsh. Q1. How to handle this situation ? Q2. What measure we should take at application level so as to reduce this possibility ? (by now many devices has been installed in the filed) Help me , Waiting your reply Regards Manish
Nothing happens randomly. What events correspond with the corruption?
Paul G. Tobey [eMVP] replied to Manish on Thursday, April 29, 2010 11:03 AM
Nothing happens randomly. What events correspond with the corruption? It should be obvious that, if you are in the middle of writing a file or otherwise modifying the filesystem contents, that is going to result in an update of the FAT. If power is lost during that process, there is no way to assure that the update is completed cleanly. The device OEM has to support you to fix this. Maybe they add a battery and an indicator to the software that says, "Main power lost. Save your work", and gives you enough run time to make sure that all file I/O is flushed before the system shuts down. They could, alternatively, use one of the transacted FAT filesystems out there (one is available from MS). That should limit the severity of the error (although it should be obvious that any file data you are in the middle of writing when power goes out is unlikely to survive). There is no registry change that suddenly changes the laws of physics; you have to *engineer* a solution that works for you. Paul T.
Thaks Paul for the reply .
Manish replied to Paul G. Tobey [eMVP] on Thursday, April 29, 2010 9:33 PM
Thaks Paul for the reply . I must tell you that we are using watchdog timer ,and we stop feeding it whenever it crosses some thresholds . We at our application make sure that we do not write anythig in the Flash when it is going to reboot . What is the minimum time requred by O/S before we reboot (watch dog time feed) Waht else we can do at application level .. Regards Manish
Manish,As Paul said, you have to engineer the solution.
Charlie replied to Manish on Friday, April 30, 2010 6:47 AM
Manish, As Paul said, you have to engineer the solution. I have had to address this in my application, and the basic solution was to avoid writing to my flash device unless absolutely necessary. There are two issues at work here - the FAT table and the data itself. Obviously, if something is updating the FAT table, and power is lost, you run the risk of losing your "disk". If you are writing data, you run the risk of losing the data. From an application perspective, you can minimize your exposure; however, if you want to be 100% sure, you must have platform support, meaning you go back to the vendor. cg
Hi Charlie/PaulThis conversation has clicked one idea ,i do not know whether
Manish replied to Charlie on Friday, April 30, 2010 10:09 AM
Hi Charlie/Paul This conversation has clicked one idea ,i do not know whether it is workable or not but i must mention here : We are ready to lose data but not the disk (FAT) . In our appication case we maintain 5 folder which are created every day changeover and each contain some file of variable size. I propose that ,at the first run of our application we create ,all (5) folders each contains a file with dummmy data, and the file size would be the maximum size expected in the application. And we will update the same file in respective folder with actual data as we are updating now ,remainig bytes will be filled with dummy data to keep the data size same as max file size. This way the file data will be always written in the same sectors of the disk and there will be no updation in FAT table . Please advise, how feseable this idea is ? Regards Manish
You do not know where data will be saved.
Paul G. Tobey [eMVP] replied to Manish on Saturday, May 01, 2010 12:01 AM
You do not know where data will be saved. Although the data might be saved in the same logical sector of the flash disk, that does not mean that it will actually be saved in the same location in the flash. Flash has a limit to the number of times you can write a given block, so the flash drivers almost universally do what is called "wear leveling", by distributing writes around the flash chip while making it look like a "disk". Although what you are saying will not be any worse than what you have right now, I doubt that it will be any better. This is a case where you either need to fix it correctly, with a fault-tolerant filesystem and appropriate hardware, or you have to prevent the error entirely, by putting a uninterruptible power supply or battery in the system. Paul T.
The information you got from MOXA that the file system is corrupting becauseof
S3c2410_invader replied to Manish on Monday, May 03, 2010 9:33 PM
The information you got from MOXA that the file system is corrupting because of WinCE FAT not necessarily 100% true. In our system we are using NAND flash and NOR flash. We have done various power failures testing in our device with NAND flash but we could not find this issue. However we have data corruption issue for other reason but we have manage to fix it. I have few suggestions for you.
NOR flash is much slower in writing data than other device like NAND flash. So whenever you write to file system it takes long time to complete the writing process. If any power failure happen in the middle writing process, almost certain to have data corruption issue. SLOWER DEVICE IS (WHEN USE AS A FILE SYSTEM) ALWAYS PRON TO POWER FAILURE ISSUE. We have tested several device like NOR, ORNAND etc. have power failure issue. Manageable but Needed lots of driver fine tuning; the manufacturer driver provided with chip is not design for windowCE. Use proper shutdown method similar to PC (WindowCE also provide this option) instead of direct power off. Provide uninterrupted power supply.
Avoid NOR flash as file system device instead use NAND flash as file system and NOR flash for only booting the system(Read only from NOR flash unless you handle the power failure and slow writting process) Low level driver implementation is also critical for achieving data reliability in the NOR flash device. So you may use the third party file system like.... Because WindowCE file system do lots of thing when you write a data. Good luck.
