Posts by martinmoe

    The problem is that the aforementioned DeviceIoControl returns failure after some runtime (with many transfers prior to failing). I cannot provide the exact value or if the function is ok again in the next call. It occurred in an end user application and I have only the information that the communication failed while communicating with at least 2 different devices (of different kind) on the bus.

    I would like to know if the named issues fix any problems that may occur after some runtime or if the issues just fix things that would fail immediately. Or in other words: I want to know if the problem may be solved if we update to the latest kernel and drivers. Because if you didn't fix anything which is a problem after some runtime, the fixes are not relevant for us. (Updating the kernel in the field cannot be done).

    Of course there could also be some electrical problem in the attached hardware, but when the device is powered off and on again, the problem is gone, which makes software suspicious.

    Does the NI2C allocate memory in any form to do a transfer? If yes, then the "small memory leak" issue may also have an influence and the problem may be solved by using V2.20 or higher (issue 0003112).

    I want to avoid an kernel update as long as I am not entirely sure the Update fixes the problem.


    we have at least 2 efusA9 Boards with the WEC 2013 V1.80 Firmware which experienced problems with the I²C (NI2C) after a long (probably several weeks) runtime.

    Boards with V2.30 and newer have not yet shown such behavior. We are using I2C_B with no IRQ but write and read (with repeated start condition).

    There are several Issues concerning NI2C (FSiMX6 Changelog.txt):

    - 0003298: [NI2C] Setting values of drive strength and pull up doesn't work - resolved

    - 0003294: [NI2C] Bus toggle doesn't work correctly if it is lock up - resolved

    - 0003074: [NI2C] Repeated start does not work - resolved

    - 0003040: [NI2C] Sometimes occurs an exception while boot process - resolved

    - 0002935: [NI2C] efusA9: I2C_B_IRQ is configured as output - resolved

    My question is: Are these issues addressing problems which may occur after a long runtime?

    Here is a snippet how we use the driver:

    1. NI2C_MSG_HEADER txrxRequest[2] = {
    2. { (addr << 1) , 0x00, writeCount },
    3. { (addr << 1) | 1, 0x00, readCount }
    4. };
    5. result = DeviceIoControl(m_hI2CDevice, IOCTL_NI2C_TRANSFER, reinterpret_cast<LPVOID>(&txrxRequest[0]), sizeof(txrxRequest), pWriteReadBuffer, writeCount + readCount, NULL, NULL);
    6. ...

    Kind Regards



    this is just a bug report:

    NDCUCFG Version 61 crashes on EFUSA9 V2 with the "device enum" command on both, the command line and the serial port.

    Exception 'Data Abort' (0x4): Thread-Id=01900006(pth=c08a83b8), Proc-Id=018e0006(pprc=c08a46f8) 'ndcucfg.exe', VM-active=018e0006(pprc=c08a46f8) 'ndcucfg.exe'
    PC=42424b9d(ndcucfg_lib.dll+0x00004b9d) RA=42424b4f(ndcucfg_lib.dll+0x00004b4f) SP=0003e8f8, BVA=001a912c


    I tested WEC2013 1.50 by just watching the System Properties / Memory Tab and also notice the approx. 12KB/h increase of Program Memory in use:

    Time Program Memory In Use
    11:35 158624 KB
    11:55 158632 KB
    12:45 158636 KB
    13:10 158640 KB
    14:25 158652 KB
    15:00 158656 KB

    I will keep the system running without any external interaction and report my observations.


    thank you for the Information.

    Is there a way to disable the watchdog? I do not need it, we have our own watchdog on the carrier board.

    I provide the following Information as it might help your colleagues finding a solution:

    After one of my boards was reset by WDOG, the board behaved strange: Yesterday in the evening the USB Keyboard was working but, today in the morning it didn't work anymore. I left the Board powered up over the night. I reset the board with the reset button (connected to RESET IN). My custom application started up as usual. The Serial Debug Port shows the following messages upon every access of the I2C B Bus:

    Start condition or Repeated Start can't be launch.NI2C3: The bus idle.
    Start condition or Repeated Start can't be launch.NI2C3: The bus idle.

    The only devices connected are one PCA9555 and one TMP175.

    My oscilloscope shows continoues LOW for I2C_B_DAT and continous HIGH for I2C_B_CLK.

    This error state is preserved even after hardware resets!
    After power down and power up the I2C is working again.


    I am observing occasional resets of the EFUSA9 Solo CPU Board. Occasional means: after 3 hours, after 1 day and after nearly 2 weeks.

    I have been observing the serial debug output. There is no error or crash printed. The output from the rebooting board reveals the reason for the restart: WDOG or Watchdog

    How can i find out what causes the "WDOG" to reset the board? My 5 V supply (up to 3 A) measures 4.983 V, the supply of the TFT display measures 3.232 V.

    I am using the NSPI, NI2C, Ethernet and a LVDS attached display NEC NL10276BC13-01C which is powered by the EFUSA9.

    Serial Output:

    UFN: Version 1.1, ActiveKey = Drivers\Active\74
    INFO:OALLogSetZones: dpCurSettings.ulZoneMask: 0xb

    Microsoft Windows CE Bootloader Common Library Version 1.2 Built Oct 9 2015 17:44:45
    Microsoft Windows CE Bootloader for efusA9 Built Oct 9 2015
    Portions copyright (c) 2012 F&S Elektronik Systeme GmbH
    Boot Loader, Version 1.20
    NBoot, Version VN25
    HW rev. 1.10

    HW-Watchdog: ON
    System ready!
    Preparing for download...
    Press >S< to step into monitor...
    AUTO BOOT enabled
    Image Signature in Flash Memory found (dwSig=0x43454345)
    TOC pointer=0x80491A48

    ROMHDR (cTOC = 0x00271a48) ---------------------
    DLL First : 0x4001efd7
    DLL Last : 0x4013f000
    Physical First : 0x80220000
    Physical Last : 0x804fa518
    Num Modules : 32
    RAM Start : 0x80620000
    RAM Free : 0x8066b000
    RAM End : 0x90620000
    Num Copy Entries : 2
    Copy Entries Offset : 0x802bdfe0
    Prof Symbol Length : 0x00000000
    Prof Symbol Offset : 0x00000000
    Num Files : 8
    Kernel Flags : 0x00000001
    FileSys RAM Percent : 0x20202020
    Driver Glob Start : 0x00000000
    Driver Glob Length : 0x00000000
    CPU : 0x01c4
    MiscFlags : 0x0002
    Extensions : 0x80221f00
    Tracking Mem Start : 0x00000000
    Tracking Mem Length : 0x00000000
    Kernel (2921kB) read from flash disk started finished in 1000 milliseconds
    Kernel read from NAND
    INFO: OEMLaunch: Jumping to Physical Address 0x10220000h (Virtual Address 0x10220000h)...

    Jumping to Kernel @ 0x10220000
    INFO:OALLogSetZones: dpCurSettings.ulZoneMask: 0xb
    Windows CE Kernel for ARM (Thumb Enabled)
    Enabling L2 cache
    OEMInit: silicon rev = 0x12
    SMP support disabled

    efusA9 V1.60 - Firmware Init
    Copyright (c) 2013 F&S Elektronik Systeme GmbH
    Build: Oct 16 2015/20:01:55
    [OAL] MACB: Disabled
    [OAL] RestartReason: WDOG
    FSPART: FS partition driver loaded
    BINFS: RegisterVolume - Mounted volume '\BINFS'
    BE2: Version 1.4, ActiveKey = Drivers\Active\01
    BE2: Version 1.4, ActiveKey = Drivers\Active\04
    IPU: Version 1.3, ActiveKey = Drivers\Active\10
    HCD: Version 1.1, ActiveKey = Drivers\Active\17
    PP: Version 1.1, ActiveKey = Drivers\Active\19
    VDI: Version 1.1, ActiveKey = Drivers\Active\20
    ENET: Version 1.3, ActiveKey = Comm\ETHNETA
    BE2: Version 1.4, ActiveKey = Drivers\Active\34
    NI2C: Version 0.1, ActiveKey = Drivers\Active\35
    NI2C: Version 0.1, ActiveKey = Drivers\Active\36
    NI2C: Version 0.1, ActiveKey = Drivers\Active\37
    Serial: Version 1.4, ActiveKey =
    Serial: Version 1.4, ActiveKey =
    Serial: Port disabled. Serial debug is on !
    Serial: Version 1.4, ActiveKey =
    SHC: Version 1.2, ActiveKey = Drivers\Active\42
    SHC: Version 1.2, ActiveKey = Drivers\Active\43
    SHC: Version 1.2, ActiveKey = Drivers\Active\44
    CID: Version 2.5, ActiveKey = Drivers\Active\45
    CID: Version 2.5, ActiveKey = Drivers\Active\46
    NSPI: Version 3.7, ActiveKey = Drivers\Active\47
    NSPI: Version 3.7, ActiveKey = Drivers\Active\48
    NSPI: Version 3.7, ActiveKey = Drivers\Active\49
    PWM: Version 1.3, ActiveKey = Drivers\Active\50
    EXTRTC: Version 1.2, ActiveKey = Drivers\Active\51
    SHC: [USDHC3] SD card inserted
    PPU: Version 1.1, ActiveKey = Drivers\Active\53
    BCS: Version 1.4, ActiveKey = Drivers\Active\54
    DIO: Version 1.4, ActiveKey = Drivers\Active\55
    FRW: Version 1.3, ActiveKey = Drivers\Active\58
    GALCORE 4.6.9(9754) (Aug 13 2014 10:51:18)
    Major GPU: SysIntr=34 MemBases=0x130000 MMU Version=0
    2D GPU: SysIntr=35 MemBases=0x134000 MMU Version=0
    Video memory: BaseAddress=0x0 PhysBase=0x106cc000 size=0x7000000 physSize=0x0
    LCD: Version 1.0, ActiveKey = Drivers\Display\LCD
    LCD: Read registry settings from Drivers\Display\LCD
    LCD: Read registry settings from Drivers\Display\LCD
    LCD: Display-Mode 100, Name NEC NL10276BC13
    TchProxy: touch driver cann't be loaded. Check touch driver registry settings.
    NDCUCFG V 61 started. Platform: efusA9
    NDCUCFG Open COM1: at 115200 Baud
    CreateFile() failed -> ERROR COM1:
    CheckAutoStart: Version 1.7, LaunchNum = 100
    SoftRTC disabled


    I think there is an issue because the decrease in available physical memory can be observed with no application running, with no user interaction and no network cable connected.

    Just boot up the board, open the Memory tab in the Control Panel/System and wait. The number of Program Memory in Use will increase by about 12 kB per hour.


    I am investigating a decrease of the "Available Physical Memory" returned by GlobalMemoryStatus() of about 200 KB/day in Windows Embedded Compact 2013 (efusA9 V1.60 - Firmware, Build: Oct 16 2015/20:01:55, EFUSA9 V3 Solo; LVDS attached Display)

    Although 200 KB/day sound not that much it is too much for a system that has to be available 24/7.

    I have hunt down the problem to an Operating System Issue: When I open Control Panel/System/Memory and observe the "Program Memory in Use" for several hours, it shows the same leak rate of about 200 KB/day (12 KB in 90 minutes). This test is done without our custom application running, with no network connection and no USB devices.

    I therefore suspect something in the OS or one of the drivers.

    Is there any chance to find out the leakee?

    Works perfectly in WEC2013 F&S 1.40 on efusA9

    Here is the NDCUCFG command sequence:

    reg open \SYSTEM\GWE\
    reg set value Animate dword 0
    reg create key ANIMATE
    reg open ANIMATE
    reg set value Frames dword 0
    reg set value DelayMilliseconds dword 0
    reg save

    Attention to all developers:

    QueryPerformanceCounter() on efusA9 on WEC2013 F&S Version 1.40 seems to return a per-core counter, resulting in start time larger than stop time when a thread which measures short amounts of time runs on one core to get the start time and then on the other core to get the stop time.

    • Are there any plans to fix this?
    • How is GetTickCount() implemented? Does it use QueryPerformanceCounter() (or its time source) for the tick count? Or does it return a some OS counter?


    I downloaded the SDK (ndcucfg_lib.h and ndcucfg_lib.lib). I get this error at link time:

    1>------ Build started: Project: mcu-fw-x, Configuration: Release FSiMX6 WEC2013 ------
    1>LINK : fatal error LNK1113: invalid machine type 0x1C2
    ========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========

    Seems as if the LIB is not intended to be used with FSiMX6 WEC2013.

    I got a new SDK and then could implement using the I²C. Now I use the I2C2: device on the efusA9 (I2C_B).

    By the way: The Document WINCE_FSiMX6_DeviceDriver_eng.pdf contradicts with the actual registry settings for the Touch drivers.

    The Touch drivers have "I2C3:" set for the I2CDevice registry value.
    The PDF document states, that the Touch drivers use "I2C2:" and one should use "I2C3:" for other purposes.

    By the way, if anyone needs it: Here are my settings for the NEC NL10276BC13 TFT Display (6,5", 1024x768, LVDS):

    reg open \drivers\display\lcd
    reg set value Mode dword 100
    reg set value OutputDevice dword 16384
    reg create key Mode100
    reg open \drivers\display\lcd\Mode100
    reg del value Prefix
    reg del value ExtDll
    reg del value PWMDevice
    reg del value PWMChannel
    reg del value Freq
    reg del value DutyCycle
    reg enum
    reg set value Name string "NEC NL10276BC13"
    reg set value Type dword 0x00004006
    reg set value Config dword 0x12300000
    reg set value Columns dword 1024
    reg set value PPL dword 1024
    reg set value BLW dword 159
    reg set value HSW dword 1
    reg set value ELW dword 160
    reg set value Rows dword 768
    reg set value LPP dword 768
    reg set value BFW dword 18
    reg set value VSW dword 1
    reg set value EFW dword 19
    reg set value Width dword 132
    reg set value Height dword 99
    reg set value Bpp dword 16
    reg set value ContrastEnable dword 1
    reg set value ContrastValue dword 0
    reg set value ContrastFreq dword 20000
    reg set value LCDClk dword 65
    reg set value EnableCursor dword 1
    reg set value Rotate dword 0
    reg set value Msignal dword 2
    reg set value HVSync dword 2
    reg set value PONLcdPow dword 0
    reg set value PONLcdEna dword 0
    reg set value PONLcdBufEna dword 0
    reg set value PONVeeOn dword 0
    reg set value PONCflPow dword 0
    display mode set 100
    reg save
    reg open \drivers\display\lcd
    reg enum
    reg open \drivers\display\lcd\Mode100
    reg enum

    OK, i found out how to use BL_CTRL:

    The PWM value of BL_CTRL is the "contrast voltage". So I added these lines to my Display Config script for NDCUCFG:

    reg set value ContrastEnable dword 1
    reg set value ContrastValue dword 0
    reg set value ContrastFreq dword 20000

    The Frequency on my oscilloscope actually is 50 kHz.

    contrast set 0 -> 99,x % duty cycle (full brightness)
    contrast set 4095 -> 0 % duty cycle (completly dark)

    • Which values are allowed for the ContrastFreq?
    • How can I set the contrast from my application without spawning a NDCUCFG process?


    are the BL_CTRL and VCFL_ON signals of the efusA9 already implemented in WEC2013 F&S Kernel 1.40? Are the signals usable even if the display is connected to the LVDS connector?

    I would like to switch the display on and off and to dimm the backlight darker and brighter from our application.

    I already checked the Changelog and Roadmap but did not find anything about them. I already checked the device driver documents but I did not find information dedicated to the efusA9.