Posts by martinmoe

    Hello,


    the Firewall Service (FWS0) on my efusA9 with WEC2013 F&S Kernel Version 3.90 does not start automatically. It is possible to start it later with "services start fws0:".


    1. Why does it no start automatically? Is that always the case?
    2. Shouldn't it load and start when Flags are 0x10 (16)?
    3. Is there any other "enable" flag? (like HKLM\Comm\FTPD\IsEnabled:DWORD for the FTP Server)?

    HKEY_LOCAL_MACHINE\Service\Firewall<br>

    "Filter"=multi:{299A39FC-4CF2-4c18-9A17-2F097601DF33}<br>

    "UserProcGroup"=dword:2<br>

    "Flags"=dword:16<br>

    "Dll"=string:FIREWALL.Dll<br>

    "Order"=dword:9<br>

    "Keep"=dword:1<br>

    "Prefix"=string:FWS<br>

    "Index"=dword:0


    Kind Regards

    Martin

    Hi,


    It's WEC 2013 on efusA9 here. Is there any way to either

    • close the NetBIOS UDP ports 137 and 138 (most likely opened by netbios.dll) or
    • filter out the UDP ports 137 and 138 with the WEC2013 Firewall (Service FWS0: done by FIREWALL.DLL) (Filtering works, but I couldn't figure out the correct way to set up the necessary allow-rules for our app)

    I could neither achieve the first, nor the second.


    Kind Regards

    Martin

    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.

    Hello,


    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:

    Code
    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

    Martin

    Hello,


    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

    Hello,


    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.

    Hello,


    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.

    Hello,


    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
    +ReadKernelRegionFromNandFlash
    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'
    PM-NETDCU: STARTED
    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


    Hello,


    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.

    Hello,


    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?

    Thanks!
    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