Posts by Habi


    Can you explain a little bit more in detail where your backlight is connected and whether you are using such an RGB adapter or not.

    To my knowledge there is no RGB adapter used, but I have to clarify this with our hardware department.

    The backlight is controlled via the signal BL_CTRL (PWM backlight dimming). VCFL_ON is NOT connected.

    A constant low level at BL_CTRL means backlight off.

    For Windows we use display mode 9 in Eboot. The setting of mode 9 works out of the box without further modification. Is it possible to get the details of mode 9 so that we can transfer it to the lcd_wvga struct?


    >> ... 100 mA and rejects USB devices which ask for more current?

    << Overcurrent detection by the CPU can only be done in the context of USB Specification Revision 2.0. So i asume you Need additional HW.

    I'm rather thinking about a software solution. Windows manages the total current of USB ports by evaluating the current information provided during enumeration. E.g, if a bus-powered USB hub is connected to which in turn several bus-powered USB devices are connected. In this case Windows would reject devices if the total sum of current the devices claim to require gets greater than 500 mA. As far as I know this is not done via the overcurrent detection realized in hardware.

    My idea was to decrease the software limit from 500 mA to 100 mA via registry setting or something like that.

    Regarding the problem with the hub:

    The hub I used for my first test do not work, which means a USB stick connected via this hub is not recognized by the efus-board. Setting PhysicalPageSize as suggested didn't change anything. But other hubs work as expected (even without increasing PhysicalPageSize). For my first test I picked the only USB-hub we have in the company which do not work :-)

    The hub which is not working is the D-Link DUB-H7. I can live with that, using a hub is not a use-case in this project.

    Hello Support-Team,

    Is it possible to configure the USB host functionality in a way so that only one bus-powered USB device is enumerated which claims a maximum current of 100 mA and rejects USB devices which ask for more current?

    Background: We use a battery driven efusA9X board with WEC2013 and want to limit the current provided by the USB port to avoid that USB devices deplete the battery too fast.

    The device supports the USB classes mass-storage and printer.

    In this context I have noticed that the USB host at our device does not support external hubs (self made kernel). I'm wondering if it is possible to add support of hubs? I have found no appropriate catalog item to do so.

    Best regards,



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

    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

    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,


    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.

    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".


    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,


    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,


    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:


    - Kernel: 128 MByte

    - FFSDISK: 1024-128 = 896 MByte

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



    - 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

    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).

    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?


    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


    - 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,


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


    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



    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:

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

    And my changes:

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


    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:


    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,


    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.



    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,