Posts by fs-support_ZU

    >> This is what I did for efusA9XR2 to get the same behaviour as on efusA9X (since we did not use explicit RegFlushKey() on efusA9X either and registry persisted).

    << I can't believe this. The only difference between A9X and A9XR2 is the Ethernet phy!

    And bit 1 is set. Flags it a evaluated bit wise and 3=1|2.


    PS: Sorry you said RegistryFlags I thought about Flags. Nevertheless there are no differencies between A9A and A9XR2 and I would use RegFlushKey.

    Hello,


    thanks for this information.


    Flash:

    I don't know anything a "auto reg flush feature" but I would not use it at all.

    Keep two things in mind, write cycles to Flash are limited and using FAT, power off while writing may demage the FAT. So I would prefer explicite call of "reg save" (which implicite calls OS function RegFlushKey()).


    SD:

    which SD Card you are talking about? Can you give me the pins or index in Registry.


    PS: do delete your [HKEY_LOCAL_MACHINE\init\BootVars] in OSDesign.reg and use default. This is safe.

    Else msdn is your friend.

    Dear Vladimir,


    thanks for this information. I will check it asp.


    Differencies between Flash- and SD drivers on efusA9XR2 and efusA9X are marginal and our standard image works on efusA9XR2. So I assume it may be a configuration issue while the BSP creation.

    Hello Bernard,


    >> Our procedure was made for PicoCOM4 (2011) and we receive PicoCOM4.2 without WARNING message that indicates a board version change!!

    << You or your distributor got a PCN about the required changes between PicoCOM4 and PicoCOM4.2! And when you get PicoCOM4.2 you had explicit ordered them.


    >> Is it a way to recover the possibility to upload this time the last eboot_pc4_112.nb0 file

    << If you can still step into NBoot (startup + DCUTerm + s) you can try to download EBoot via serial (DCUTerm->File->transmit binary file->...) or via USB (NetDCUUSBLoader). Use command "d" for this purpose.


    Hope this helps.

    Hello,


    please tell me what are your doubts? <port2> is just a placeholder if you would like to continue to configure futher ports. Else skip it. I better had wrote "reg set value UseAsIO hex 0xf8,0x07,<port2>, ..., <portN>". But I thought it was clear in context with Device Driver Doc. (one byte one port)! Sorry.


    Code
    1. Port 0
    2. Pin 0 1 2 3 4 5 6 7 on 66 pol. feature connector
    3. - 3.3V 5.0V GPIO GPIO GPIO GPIO GPIO -> you want to use pin 3-7 so bit 3-7 is to set -> 0xf8

    analog for port 1!

    So if you just use port 0 and 1 set "reg set value UseAsIO hex 0xf8,0x07"


    Did you test my settings above at all?

    Are you detect any issues with our SW?

    Hello,


    we changed notation for DIO, refer DeviceDriverDoc, because newer boards may have much more IOs than 32. You can still use "dword" notation but with suffix (UseAsIOA (port 0...3), UseAsIOB (port 4...7), ...)


    1) Which exact pins are corresponding to GPIO port 0 on A9r2: pins from 3 to 10 of the 66 pins feature connector ?

    Pin 3...7 belongs to port0

    Pin 8...10 belongs to port1


    2) We try to configure 4 pins In and 4 pins Out altenatively, so on WCE register we set

    reg open \drivers\builtin\digitalio

    reg set value UseAsIO hex 0xf8,0x07,<port2>,...,port<n>

    reg set value DataDir hex 0xA8,0x02,<port2>,...,port<n>

    reg save

    REM


    Hope this helps.


    PS: switch off unused SPIs because they may use the same pins:

    reg open \drivers\builtin\armStoneA9R2\spi2

    reg set value Flags dword 4

    reg open \drivers\builtin\armStoneA9R2\spi3

    reg set value Flags dword 4

    reg save

    REM

    Hello,


    We can only provide support for standard versions of the PicoCOMA5.


    In this case, the customer's software is used and we do not have access to it. Please clarify with the customer directly.

    Thank you for your understanding.

    Dear Vladimir,


    we put new BSP which supports also efusA9xr2 into the download. Please test and let us know if everything works fine on your side.

    I put also new "kernel update tool" into your custom downlaod. Here (new introduced) FCR driver is terminated before the update. FCR does dynamically check the Flash for consistency.

    >> We worked with version 180316 and I see that this version is skipped in the kernel history?

    << You are right. But I found no information about the changes also not im my emails from around 180316.

    So we unfortuneatly lost this information.