Re: TFAT stability

The problem is rather simple: if you look at how the msflash block driver is implemented, you can see that disk-like 512-byte sectors are mapped plain linearly to flash memory. Well, what if you must write a sector in a flash block already in use? You need to back up data somewhere, erase the 128k block (which can take 1 second) and restore the modified block content.
All this is done in the FAL (Flash Abstraction Layer), which is not documented. Are we sure that FAL can recover, say, if power fails in the middle of a block erase?
Note: TFAT knows nothing of flash blocks. It does safe transactions with 512-byte sectors.
Using a CF card leaves the task of virtualizing 512-byte sectors out of a flash array to the microcontroller firmware inside the card, which is supposed to be heaviliy tested.

Regards.

Marco Contenti
PROJECT s.a.s. (WEP)
www.projectsas.it
marco.contenti@<see domain above>

turnsek ha scritto: 
Thanks for the reply.

The problem is we don't have the WinCE5.0 yet.
We have turned off AutoScan and the platform seems to be stable (for now). We are perfoming powerdown and powerup tests for now and we'll see if it will survive overnight. I shure hope so. Regarding the AutoScan, I think the filesystem moust be unmounted during this scan and as that is not protected from powerdowns. This might be the problem during powerup. So I have removed AutoScan and we will see. I shure hope so that there is no bug in the TFAT implementation or Msflash block driver implementation.

O, yes. We have another platform with WCE4.2 and SH3 processor with CF card. The configuration is almost the same. TFAT filesystem is on the CF card and we don't have any problems. We had similar problems with FAT filesystem, but when we switched on TFAT, everything was ok. So, the problem may be in block driver and not the TFAT. What do You think?

Thanks, Jernej 


"<ctacke/>" wrote:


I've actually got an open case with Microsoft on this issue. Their first suggestion, which I'm in the process of implementing, was to take the TFAT stuff from CE 5.0 and pull it into my 4.2 platform and see if that fixes it. I'm not done yet, so I don't know if it fixes the problem, but you might try the same.

-Chris



"turnsek" <turnsek@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:2617B633-7B34-41D8-A06F-7035956A920A@xxxxxxxxxxxxxxxx

Yes, the flash modifying is the issue here, but why? I have tried to remove
the registry hives from the flash to RAM and now my filesystem crushes, but
at least the platform boot itself (ethernet is working etc.). All files are
missing on my storage card (we are using Intel StrataFlash J3). I have also
tried to make two partitions, both with files written to them. In normal
operation the application is only on the first patiition and all the wriiting
and reading is done to that partiion. After crash, only files on this
partition are missing. The second one is ok.

Do I have some registry settings wrong for the TFAT or is it something else?
I have check the newsgroups and it seems to me that a lot of folks are having
this kind of problems. But there is no solution proposed except for "UPS
kind" of backup during power down. This is not an option for us. Microsoft
also said that TFAT is safe and stable. Ok, there could be an issue with the
msflash strata driver, but that is also supplied by them. So, where is the
catch? I' ve ruled out the hardware problem, because there is the consistency
about filesystem crash. If it would be hardware then there would be problems
with image and bootloader too and not with filesystem only.

Thanks, Jernej

"Bruce Eitman (eMVP)" wrote:


I have also seen these failures on a few platforms, both CE 4.2 and 5.0. I
think that it has a lot to do with background compaction and removing power
while the flash is being modified.

--
Bruce Eitman (eMVP)
Senior Engineer
beitman AT applieddata DOT net

Applied Data Systems
www.applieddata.net
An ISO 9001:2000 Registered Company
Microsoft WEP Gold-level Member


"turnsek" <turnsek@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A6C143B2-6D21-49DF-8F05-B5950ECE3A2A@xxxxxxxxxxxxxxxx

Hi all!

We have PXA255 based platform with WCE42 and we are testing stability of 

the

platform. Our hardware is not battery backed and we rely on powerdown 

driver

and TFAT file system. We have noticed that after number of power down and
power up cycles (quite a lot) our platform dies. We have flash resident
persistent registry (hive based). Platform could not start anymore. I am
suspecting that the file-system is corrupted (so the registry too). We are
using msflash strata driver.
Our settings are:

[HKEY_LOCAL_MACHINE\System\StorageManager]
"Dll"="fsdmgr.dll"
   "PNPUnloadDelay"=dword:0

; @CESYSGEN IF CE_MODULES_STRATAD
; HIVE BOOT SECTION
; StrataFlash block driver.
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\StrataFMD]
  "Dll"="stratad.dll"
  "Order"=dword:2
  "Prefix"="DSK"
  "Ioctl"=dword:4
  "Profile"="MSFlash"
  "IClass"="{A4E7EDDA-E575-4252-9D6B-4195D48BB865}"
  "MemBase"=dword:b9300000
  "MemLen"=dword:03000000
  "Flags"=dword:1000

; Override names in default profile
[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\MSFlash]
   "Name"="MSFLASH for STRATAFLASH"
"Folder"="Storage Card"

[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles]
   "AutoMount"=dword:1
   "AutoPart"=dword:1
   "AutoFormat"=dword:1

; Keep FATFS from trying to shadow \Windows
[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\MSFlash\FATFS]
   "MountFlags"=dword:2

[HKEY_LOCAL_MACHINE\System\StorageManager\AutoLoad\MSFlash]
   "DriverPath"="Drivers\\BuiltIn\\StrataFMD"
   "LoadFlags"=dword:1
   "Order"=dword:0

; END HIVE BOOT SECTION
; @CESYSGEN ENDIF CE_MODULES_STRATAD


; @CESYSGEN IF FILESYS_FSREGHIVE
; HIVE BOOT SECTION
[HKEY_LOCAL_MACHINE\init\BootVars]
  "SYSTEMHIVE"="Registry\\system.hv"
  "PROFILEDIR"="Registry"
  "Start DevMgr"=dword:1
  "DefaultUser"="Iskraemeco"
  ;Causing some debugchk's in debug version,
  ;performance monitoring tools doesn't work.
  ;RegistryFlags"=dword:1
; END HIVE BOOT SECTION
; @CESYSGEN ENDIF FILESYS_FSREGHIVE

[HKEY_LOCAL_MACHINE\System\StorageManager\FATFS]
   "FriendlyName"="FAT FileSystem"
   "Dll"="fatfsd.dll"
   ;"Flags"=dword:00000024
"Flags"=dword:007C0028
   "Paging"=dword:1
   "EnableCache"=dword:1
   "CacheSize"=dword:0
   "Util"="fatutil.dll"
"FormatTfat"=dword:1
; END HIVE BOOT SECTION
; @CESYSGEN ENDIF CE_MODULES_FATFSD


Any help would be more then welcome.

Thanks, Jernej






.

Relevant Pages

  • Re: TFAT stability
    ... you can see that disk-like 512-byte sectors are mapped plain linearly to flash memory. ... TFAT knows nothing of flash blocks. ... We have turned off AutoScan and the platform seems to be stable. ... I think the filesystem moust be unmounted during ...
    (microsoft.public.windowsce.platbuilder)
  • Re: TFAT stability
    ... So you think there is no solution to stabilize the filesystem? ... you can see that disk-like 512-byte sectors are ... > mapped plain linearly to flash memory. ... TFAT knows nothing of flash blocks. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: TFAT stability
    ... > when we switched on TFAT, ... > driver and not the TFAT. ... > We are perfoming powerdown and powerup tests for now and we'll see if it ... TFAT filesystem is on the CF card ...
    (microsoft.public.windowsce.platbuilder)
  • Re: TFAT stability
    ... >>> when we switched on TFAT, ... >>> driver and not the TFAT. ... >>> We are perfoming powerdown and powerup tests for now and we'll see if ... TFAT filesystem is on the CF card ...
    (microsoft.public.windowsce.platbuilder)
  • RE: Flash filesystem performance
    ... During these tests we are checking the STS pin of the flash and it is ... Currentlly I am not able to do a lot of these tests with TFAT system because ... my boss wants the product fast and I must stick up with the IPSM filesystem ... > this allows it to know there is always something free during compaction. ...
    (microsoft.public.windowsce.platbuilder)