Re: TFAT stability



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: Why to use VBA?
    ... Please don call me selfish for not counting VB; YES MS did lose some VB developers that were unwilling to port to new platform BUT the number of office customers is not comparable to VB 6! ... The fact is that VB.NET is sufficiently incompatible with the previous version of VB (VB6, from which VBA is derived) that for all practical purposes an upgrade wasn't possible, you had to rewrite the code more or less from scratch. ... The automated code converters provided by Microsoft were next to useless, and the fact that Microsoft went and changed lots of names of objects and properties meant that late-binding code wouldn't work without rewrite because it couldn't be automatically converted at all. ...
    (microsoft.public.word.vba.general)
  • 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: .NET SUCKS --- READ FOLLOWING. MICROSOFT IS A SUCKY CO
    ... .NET is not cross platform and Microsoft have never claimed it to ... Shared Source CLI Implementation is a file archive ... In addition to the CLI implementation and the ...
    (microsoft.public.dotnet.framework)
  • Re: My Migrations
    ... I used to say all my dreams were in COBOL. ... Development and deployment platform based on SOA and Smart Client ... All source languages are translated to C#. ... The fact is that MicroSoft DID have some bad products and they still have ...
    (comp.lang.cobol)
  • Re: My Migrations
    ... I used to say all my dreams were in COBOL. ... Development and deployment platform based on SOA and Smart Client ... All source languages are translated to C#. ... The fact is that MicroSoft DID have some bad products and they still have ...
    (comp.lang.cobol)