Posts by Habi

  • How to gracefully power-off?

    Hello,


    We are using WEC2013 on efusA9X boards. To power off the device we do the following:


    Code
    1. 1. Finish file operations in our application.
    2. 2. Call SetSystemPowerState(NULL, POWER_STATE_USERIDLE, 0);
    3. (leads into the same power state as ndcucfg's "ScreenOff" does).
    4. 3. Wait 1 second.
    5. 4. Switch power of the efusA9X-board off.


    When doing so, is there a risk that there is still data in the cache of the file system that has not yet been written, if power management is enabled in the kernel?


    Would it be better to call

    Code
    1. FileSystemPowerFunction(FSNOTIFY_POWER_OFF);
    2. PowerOffSystem();

    before switching off or is this done by the power management anyway when entering POWER_STATE_USERIDLE?


    Best regards,

    Habi

  • Change Level of Backlight-Signal for "Backlight off/ScreenOff"?

    After updating WEC2013 and the BSP/PRJ to the current versions the display becomes dark again when switching into power state "screenoff". What not works is switching off the backlight via ndcucfg, but this is not required for my project. So from my side no further actions are required. To summarize the current situation:

    • Power state "screenoff": Both signals BL_CTRL (PWM backlight dimming) and VCFL_ON (backlight on) gets stable low => display is off
    • "Backlight off" via ndcucfg: BL_CTRL (PWM backlight dimming) is not changed, VCFL_ON (backlight on) gets stable low => in my project the display remains on.

  • Drive Strength

    I'm also no hardware expert, but to my knowledge the drive strength has influence on the shape of the edges, rather independent from the frequency, at least as long as the signal reaches a stable high or low level. Our hardware department just asked me if it is possible to change the drive strength of I2C, SPI, UART and GPIO signals. I have learned that it is possible for I2C, SPI and UART, for GPIO not. I check with my colleagues if they have a problem with the drive strength for GPIO signals or if they just want to make some cosmetic fine tunings.


    By the way, what is the registry value for the drive strength of the UART signals? In your comment above you wrote "DriveStrength", but for I2C, LCD, SPI it is "DrvStrength".

  • Drive Strength

    Hello,


    Is it possible to set the drive strength for UART and GPIO (OS is WEC2013)?

    According the driver documentation the registry value DrvStrength can be used to set drive strength for I2C and SPI, but there is no such a registry key for UART and GPIO.


    Best regards,

    Christian

  • Change Level of Backlight-Signal for "Backlight off/ScreenOff"?

    Dear Support-Team,


    We use the efusA9X board with CE7 and currently migrate to WEC2013. When setting the system power state to "ScreenOff", CE7 sets the backlight signal BL_CTRL (PWM backlight dimming) to constant low and VCFL_ON (backlight on) to low. In this case the display becomes dark as expected. Everything is fine so far.


    The display mode is mode 9. We use only BL_CTRL, VCFL_ON is not connected.


    For WEC2013 the behavior of the backlight PWM signal BL_CTRL seems to have been changed. In opposite to CE7 the level of BL_CTRL becomes constant HIGH in "ScreenOff" power state instead of LOW. Thus the display stays bright. (VCFL_ON changes to low, but - as mentioned - we do not use this signal).


    ndcucfg's "backlight off/on" has no effect in WEC2013, dimming via changing the contrast works.


    Is this change a bug or a feature? :-)


    Is it possible to change the behavior of BL_CTRL so that it is constant low as it was in CE7 instead of being high when in power state "ScreenOff"?

    Is there a registry value, an ExtEscape sequence, a driver parameter or any other hack that allows to change this behavior?


    Best regards,

    Christian

  • Discspace Problem with 1GByte Flash

    Okay, in the meantime I got two further efusA9X boards. Even after resetting the bootloader via the 'C' command Eboot showed that the boards have 1 GByte of flash. Nboot shows the expected 512 MBytes, see the following logging:



    Unfortunately it is not possible to enter the size of the last partition "SECOND" manually, Eboot assigns automatically the not used space to it. This means that I have two options:


    a)

    - Kernel: 128 MByte

    - FFSDISK: 1024-128 = 896 MByte

    - SECOND: 0 MByte (automatically assigned by Eboot).


    or


    b)

    - Kernel: 128 MByte

    - FFSDISK: 512-128 = 384 MByte

    - SECOND: 512 MByte (automatically assigned by Eboot).


    In both cases Eboot tries to access not existing memory to make the partitioning and to format the partitions. Which one is less worse, a) or b)?

    I tried both. When doing b) the installed kernel did not start (kernel stopped at the second BE2....), after resetting the device Eboot was lost. When doing a) the kernel started, also after powering on/off. So option b) seems to destroy at least less than a).



    But independent weather a) or b) is done, I always have to install Eboot after doing the partitioning with the parameters shown in a) and b). Is this normal? If I partition the flash and power the device off/on, Eboot is lost (Nboot shows the command line automatically with the hint that there is no Eboot). After flashing Eboot in Nboot via the serial interface. I can use Eboot to install the OS-image.

    Is this a normal behavior or can this be caused by the problem that Eboot works with the wrong size of the flash?


    Nboot: VN32

    Eboot: Version 1.4

  • Discspace Problem with 1GByte Flash

    Thank you very much for clarifying what the partitions are for.


    >> Which size is shown for ffsdisk under cmd.exe?

    The command ">dir \FFSDISK" shows that about 340 MBytes are free. I have installed about 25 MBytes in this directory, so that

    in total in FFSDISK are about 375 MBytes available.

    Together with the 128 MByte for the OS-image (Part01) this is pretty close to 512 MByte.


    >> Are you sure using efusA9X-V8-W13 (checked by serial number info at our homepage)?

    I checked the serial number in your homepage, and yes, it is efusA9X-V8-W13.


    >> Try reset bootloader setting "C" (afterwards you have to reconfigure the board).

    Currently I have no access to these boards since colleagues are performing tests with them. But as soon as a board is available again

    I can try this. But I'm not very optimistic that this changes anything, we have two boards of this kind and both showed the same

    behavior in Eboot (1024 MByte free space for partitioning).



  • Discspace Problem with 1GByte Flash

    Okay, I think I know why Windows shows just about 512 MByte of disk space.

    We use the board efusA9X-V8-W13. I think this board has 512 MByte flash.


    I got confuse with the message from Eboot shown by the command P (see logging above):

    According to EBoot this device has 1 GByte.

    I'm assuming that Eboot is wrong here.


    Is this a bug in EBoot or do I miss here something?

  • Discspace Problem with 1GByte Flash

    Hi,


    I'm using an efusA9X board with 1 GByte flash. At delivery status it was partitioned as following

    OS-image: 128 MByte

    FFSDISK: 128 MByte

    Second: 768 MByte


    In EBoot (version 1.4) I changed the partitioning of the flash drive using the command P:

    OS-Image: 128 MByte

    FFSDISK: 896 MByte (Fat)

    Second: 0 MByte (Extended)


    According the messages in EBoot this worked fine. Even after powering off/on EBoot shows

    the correct partitioning when using the command I:

    Size of area for OS image: 128 MB

    Size of FFSDISK: 896 MB

    Format of FFSDISK: FAT


    But under Windows the Storage Manager shows:

    Capacity: 509.50 MB

    Partitions:

    - Part00: 515 Sectors

    - Part01_*: 65.537 Sectors, driver fs_binfs.dll

    - Part02_*: 194.624 sectors, driver exfat.dll


    It seems that the Windows sees only about the half of the available 1GB space which is Part00 and Part01.

    Part02, which should have size 0, got the other half of the available memory. The information Windows shows

    differs from what EBoot shows.

    Eboot shows the whished values, but Windows has its own idea about this.


    Below I added the terminal logging of the session in which I partitioned the drive.


    I could try to repartition the flash drive using Windows, but for production we would like to use

    EBoot to configure the device.


    Any ideas what is going wrong there?


    Best regards,

    Christian



    Here the logging of the session in which I partitioned the flash drive.

  • PCL-Driver for WEC7?

    Hello,


    I found some older versions of the PCL printer driver for WEC5 and WEC6 in this forum. Is there a newer version available for WEC7? We want to use it together with the USB printer class.


    Best regards

    Habi

  • Problem with adding "all" locales (out of memory)

    Solved.


    The file wince.nls is assigend to the XIPKERNEL section in config.bib. This section has a size of 4 MBytes. After increasing it to 6 MBytes and adapting the other sections accordingly building the image worked.


    The origianl settings in config.bib:

    Code
    1. XIPKERNEL 80220000 00400000 RAMIMAGE
    2. NK 80624000 03E00000 NANDIMAGE
    3. CHAIN 80620000 00004000 RESERVED
    4. RAM 80620000 0F9E0000 RAM ; size= (0x90000000-0x80620000)
    6. XIPSCHAIN=80620000


    And my changes:

    Code
    1. XIPKERNEL 80220000 00600000 RAMIMAGE
    2. NK 80824000 03C00000 NANDIMAGE
    3. CHAIN 80820000 00004000 RESERVED
    4. RAM 80820000 0F7E0000 RAM ; size= (0x90000000-0x80820000)
    6. XIPSCHAIN=80820000

  • Problem with adding "all" locales (out of memory)

    Hello,


    I'm using the BSP BSP_FSIMX6SX_WLAN_20190219 for WEC7 on efusA9X and have a problem when trying to add nearly all locales to the OS image.

    I followed this article to add the locales "Adding (all) locales to WEC7"


    When making the runtime image I get the following error message in pass 1, build.log shows:

    Quote

    Failed to find a range for data of size 1608282

    Error: Ran out of space in ROM for wince.nls size 1608282

    Fatal error hit, exiting...


    The problem seems to be the size of the file wince.nls. When removing some Chinese related LCIDs (language code identifier) from the nlscfg.inf file, the size of the file wince.nls is reduced from 1.608.282 bytes to 691.814 bytes and everything works fine.


    The overall size of the OS image (xip.bin) seems to be not the problem. The size of my xip.bin file was about 54 MBytes when I have experienced this problem. I reduced the size by removing some features to 50 MBytes and got the same error message as with the bigger image.


    I have not modified the memory mapping in config.bib.


    If I reduce the size of wince.nls so that making the OS image works, I get the following information about this file:

    In ce.bib:


    In build.log


    To reproduce this issue, please enable all Catalog Locale items in "FSiMX6SX -> Core OS -> Windows Embedded Compact -> International -> Language -> xxx -> Locale -> yyy" and use the following nlscfg.inf file:


    When removing the last 5 LCIDs (0804, 0C04, 1404, 1004, 0404, all are related to China) the size of wince.nls is reduced significantly and everything works fine.


    Any ideas what to do so that the file fits into the image?


    Best regards,

    Habi

  • eMMC on efusA9X hardware 1.10, 1.20 and 1.30 (and newer)

    I'm using the BSP BSP_FSIMX6SX_WLAN_20190219 for WEC7 on efusA9X with hardware version 1.10, but later we will update to the current hardware version 1.30.


    Regarding the eMMC there was a change between hardware 1.10 and 1.20 (using different SD-slots).


    In the registry of the BSP there are two keys for these two hardware versions.


    [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\EFUSA9X\USDHC4_REV110]

    …

    [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\EFUSA9X\USDHC4_REV120]

    …


    Every key defines with the value "GEBoardRevision" an explicit hardware version (dword:78(=120) respectively 6E(=110)).


    According to the hardware history the current hardware version is 1.30. I'm wondering what happens if this BSP is used on hardware 1.30.

    Will the eMMC work then, because the registry key with the highest version is taken automatically, which would be the key _REV120?


    If this will not work, what is the correct approach to get eMMC working on hardware 1.30 with this BSP?


    - Add a registry key for hardware 1.30?

    I don't like this because for future hardware version the registry must be updated.


    - Add a more generic key without hardware version in its name and without GEBoardRevision in the hope that this key is taken into account, if hardware 1.30 is found and that the keys ...USDHC4_REV110 and ...USDHC4_REV120 are still used for hardware versions 1.10 and 1.30?


    Best regards,

    Habi