Dear all,
With reference to this post which I earlier posted:- http://www.keil.com/forum/62296/ We are using STM32F4 based platform and running on CMSIS Keil RTX RTOS version 1. We are using 6.6 version of Keil middleware.
We are experiencing filesystem corruption problem in our system at times. Scenario can be during a sudden power loss or as part of a sequence of power off/on events.
Manually reproducing this filesystem corruption issue [In order to exact culprit of this issue] is difficult as it occurs sometimes under some scenarios.
We have enabled Journaling support and also redundant files corresponding to each of our files stored in the system keeping in mind at any point of time, only one file operation is in progress when power loss occurs. Thus keeping redundant file will corrupt only one file and system can continue to work with the other file.
But during a scenario, we got into a strange situation in which one of our file can't be opened. Even creating that file again with the same name also didn't work. Tried deleting the file and open it again. That operation too didn't work. We feel this issue is also the result of any undefined filesystem corruption behaviour.
On analysing the Keil Documentation:- System failure behavior
When File System Component experiences a power loss or crashes before a file opened for writing is successfully closed the content of that file is lost. This results in lost data clusters which can be restored using a file system repair utility tool such as chkdsk on Windows or fsck on Linux.
At another place, it is written:- In order to have a power-failure safe FS, it is better using FAT file system with a NAND flash. When writing to NAND flash, everything is committed in one step. And the NAND flash translation layer is designed to be power-failure safe as well. But note that FAT file system, which is on top of NAND flash translation layer (NFTL), is not power-failure safe. To prevent a FAT file system to be corrupted, journaling mechanism for FAT should be enabled and used in your project.
1. Did you mean even though journaling support is enabled, there is a chance that filesystem got corrupted during abrupt power failure scenarios?
2. Do you have any recommendations for preventing filesystem corruption during power failure?
3. If filesystem corruption happens, How can we use these filelsystem repair utilities (fsck or chkdsk) in system running on Keil CMSIS RTX? Is there any equivalent utilities other than fformat()?
Thank you, Lullaby Dayal
Any update on this issue? Please help us out..
Thank you, Lullaby
Have you contacted Keil Support ?
It's not uncommon to use a suitable size battery that keeps the system running during critical data commits.
Indeed - or, perhaps, (super)capacitor(s).
You'd likely need to write your own FSCK tools based on a thorough understanding of the file system and the underlying NAND memory. with it's own failure modes and ECC, etc.
Not sure you can abdicate responsibly for the behaviour of components in your system to third-parties.
You might need to determine if the system is stable enough to attempt writing, and provide power from whatever source for sufficient time to put the system into a safe state. Determine how long the write operations take, and provide a means to detect the loss of primary power early enough to be able to respond appropriately.
Consider other journalling systems, or ones which are open or come with more support. I'm sure there are companies that make a business out of providing such file systems.