none
CE 4.2 vs CE 5.0 flash chip conflict RRS feed

  • Question

  • We have a terminal that can run either CE 4.2 or CE 5.0 and what we install depends on what the customer has developed for an application.

    What has changed is the flash chips being used.  What has been obsoleted is the PC28F128P30B85A flash chip( Intel StrataFlash® Embedded Memory (P30)), and replaced with the PC28F128P30TF65E (Numonyx® Axcell™ P30-65nm Flash Memory).

    In theory the chips suppose to function identically.

    The problem is that when we load in the CE 4.2 OS, the unit boots and the OS appears to be running. but the moment we try to write to the registry(for example entering a static IP address), the operating system just hangs. If we first read from the registry, the unit works ok.

    When we load in CE 5.0 , the unit runs fine.

    Since our customers use CE 4.2 we can't move away from CE 4.2

    So I am trying to get some kind of ideas on what to look for in determining this problem. It acts like the flash memory is in  a 'read only' type more.

    The JFLASH program that loads the intial bootloader program(boot.bin) uses a .DAT file(Flash_891c_2_32.dat) to describe certian programming parameters, but I am not sure what they all mean. and there are not that many parameters.

    Just wondering if anyone else has come across this ot have ideas as to what is causing this problem.

    Thanks.


    • Edited by Chulk Ches Tuesday, May 7, 2013 9:37 PM Typo erors(again)
    Tuesday, May 7, 2013 9:29 PM

All replies

  • The Intel Persistent Storage Manager code is likely the source of the problem. It handles both registry storage and file system. It's very sensitive to things like block sizes, butting registry storage against file system storage (you may have to reduce the size of registry by 1 block to make it work), and it doesn't know about the chips you're using so initial configurations, new features, etc. won't be accounted for. It's entirely possible that some index register in the flash chip boots in a state that Write doesn't expect but that Read simply fixes.

    You might also turn on or add RETAILMSG entries to the registry storage-writing kernel functions (OEMRead..., OEMWrite...)

    Paul T.

    Wednesday, May 8, 2013 11:12 PM