Posts by al12559

    Hello everybody,
    I would be grateful if anybody could assist me in overcoming this problem:
    After I start to communicate with an I2C device, the ActiveSync connection will be closed after a reproducible duration.
    I use a PicoCOM2 with a custom-made mainboard, connected to WindowsXP using ActiveSync 4.5.
    The I2C driver is activated (with Debug=1 setting), one device (MCP23017 PortExpander) is connected to the bus and works normally.
    Serial debug shows:

    ActiveSync is connected (taskbar icon turns into green), these are the ActiveSync log files

    Now I start an application that communicates with the port expander using CreateFile/WriteFile/ReadFile on the I2C driver. Serial debug:

    Code
    1. NI2C: TWI_CWGR = 0x00029494
    2. USBFN:C_USB_DEVICE::ThreadRun: : Detach Detected

    (The "USBFN:C_USB_DEVICE" is a USB flash drive.) Exactly 106 seconds later the ActiveSync connection is closed down, the taskbar icon turns grey.ActiveSync log files show:

    Neither unplugging and replugging the USB cable nor NDCUCFG:Reboot will restore the connection, a cold reboot is required.
    --
    I tried the same setup with a PicoCOM starter kit and the same PicoCOM module. The only difference is that in this case there is no device connected over I2C.
    When I start my application that tries to connect the I2C device, serial debug output is

    Code
    1. NI2C: TWI_CWGR = 0x00029494
    2. NI2C: TWI_CWGR = 0x00029494
    3. NI2C: TWI_CWGR = 0x00029494
    4. NI2C: TWI_CWGR = 0x00029494
    5. NI2C: TWI_CWGR = 0x00029494
    6. NI2C: TWI_CWGR = 0x00029494
    7. NI2C: TWI_CWGR = 0x00029494
    8. NI2C: TWI_CWGR = 0x00029494
    9. NI2C: TWI_CWGR = 0x00029494
    10. NI2C: TWI_CWGR = 0x00029494

    I observe that the line

    Code
    1. USBFN:C_USB_DEVICE::ThreadRun: : Detach Detected

    is missing, instead

    Code
    1. NI2C: TWI_CWGR = 0x00029494

    is issued multiple times, probably due to the missing I2C device. (Both setups can't be compared I'm afraid.)
    Can you explain this behaviour? The constant time interval of 106 s before ActiveSync is disconnected (tried many times) leads to the assumption a timeout might be expired. But which? of what device or component?
    The line containing

    Quote

    Device timed out, timeout 100, iret 0, Connected 1, RLSD 1. Error 0

    in WCESCOMM.LOG might give a hint. There is no ethernet connection.
    Any help I will appreciate as the short ActiveSync life time is very annoying. Debugging an application from VisualStudio is impossible.

    As I could not find any information about the undocumented "boot display" command (not in this forum as well), using it was an effort to finally get the module running.
    Now I did what you proposed (EBoot: E and download the kernel) - at no avail. Behaviour is exactly as before.
    I suppose I should send the module to you to have it checked? How long would that take?
    Can you identify any differences between my four modules according to their serial numbers?

    Both serial debug outputs reflect the situation after configuring and activating Mode150.
    In case (3) it is the output of one of the 3 PicoCOM modules that behave normally.
    In case (4) it is the output of the PicoCOM module that remains blank (or dark).
    In that case I reset the mode by

    Code
    1. !>display mode set 2

    to the default value and received some display but not matching my display properties, just teh same as after downloading the kernel.
    After I activated Mode150 again, the result was a blank screen. Not any error messages.
    I cannot find any difference in the debug output that might indicate a deviation.

    Quote

    Is there any error message during second boot?

    Not that I'm aware of. What do you mean by second boot? I quoted the serial debug outputs of the both cases and see no difference.

    Quote

    Is your mode100 configuration in registry still available or has the registry been reset?

    Registry had been reset after downloading the kernel. Next I sent the text file with the display seetings via DCUTerm to PicoCOM and rebooted. Registry contents for Mode150 is

    I had set the "verbose" value to 1 but did not mention any additional output on serial debug.

    I still cannot get the display ET0350G0DM6 to work with one PicoCOM2 module.
    History:
    (1) Install Kernel V-1.16 with standard Hitachi display settings
    => Desktop is shown but settings do not match the ones of my display
    (2) Set up and activate Mode150 with

    (3) Using the same custom-made mainboard and the same display, these settings lead to a normal desktop display when applied to PicoCOM2
    S/N 0005 5102 3F2D
    S/N 0005 5102 3DF5
    S/N 0005 5102 116A.
    Serial debug output is

    (4) But when the same settings are applied to PicoCOM2
    S/N 0005 5102 3F3C
    the display remains dark!
    Serial debug output is

    (5)After I reset the display type to Mode2, situation is the same as in (1)


    How can I overcome this??

    Quote

    Does this mean that even the exceptions mentioned above only appear after installing this driver?

    Yes, it does. Installing this driver was part of a configuration file for various settings. After splitting it into parts for display, driver, desktop settings it became clear that the exceptions are introduced by this driver. Apart from these exceptions, the module controlled by this driver works normally. I just wanted to remove this uncertainty in the boot process.

    Quote

    The driver you are trying to use on PicoCOM2, is it build for Windows CE 6.0?

    As far as I know. I don't have the source code but may contact the developers.

    Quote

    Maybe you could check the dependecies for this dll (with depends.exe).

    This USB device driver is shown to be dependent only on COREDLL.DLL. This seems to be reasonable as it is the same with other DLLs that I use on the PicoCOM.

    This is the Debug output after resetting registry (EBoot: R) - no exceptions:


    After I install a driver for a USB device by sending the text file

    to PicoCOM, the Debug Output changes to (mention the two exceptions)


    Can you give any explanation why installing this driver causes exceptions? The device controlled by this driver works normally.

    Am I correct to conclude that the registry settings I changed are not part of the stated hash value? Their modification does not lead to a registry reset on installing a kernel.
    How can I force a registry reset to default values upon installing a kernel?

    [admin comment]
    Thread splittet from: Debug output while booting shows exceptions


    Quote

    this issue has been solved already?!

    Yes, it has. I decided to open another thread because it seems hard to get answered more than one single question at once. On the other hand, searching for questions regarding NDCUCFG is rather frustrating because this item will be ignored due to too many hits, even if ANDed with more words.


    (repeated questions:)

    Quote

    How do I set an identical clean initial state on a PicoCOM module?
    Is it sufficient to use "NetDCU USB Loader" for writing NBoot, EBoot and kernel?
    How do I secure an identical initial registry contents?

    I observed, that only writing a different kernel version than the one currently existing on the PicoCOM module seems to create standard registry settings: If e.g. display or built-in driver registry settings had been modified after installing the kernel (Glyn display type, audio and ananlog input drivers deactivated), I will find the same modified settings after writing the same kernel version again. On the other hand, if I write another kernel version to the module, I find standard settings (Hitachi display type, audio and ananlog input drivers activated)


    How can that be explained?

    Setting

    Code
    1. config = 0x00A00000

    does not help.


    My current registry settings are

    After changing "config" to 0x08000000 I was not surprised to have the correct display again as this setting was valid for all previous installations.
    What about the NDCUCFG command

    Code
    1. boot display on

    ?
    Is it required? What parameters are valid?


    These settings proved to be valid using other PicoCOM2 modules on the same custom-made mainboard with the same display.

    After I wrote the Kernel V-1.16 to a PicoCOM2 module the display settings are set for a Hitachi display. Debug Output:

    Quote

    DDGPE:Read registry settings from Drivers\Display\LCD
    Display-Mode: 150, Name Glyn G-ET035009DH6
    DDGPE:Width: 320 Height: 240 Bpp: 16
    DDGPE:InitializeDisplayHardware Complete
    EnableTouchscreen PASSED


    Actually I use a Glyn display. I apply the required settings using
    ndcucfg -B"\FFSDISK\setiings.txt", issue a "reg save" and a "reboot" from ndcucfg.
    After that Debug Output reports:


    Display remains dark. Using "Windows CE Remote Zoom-In" (Visual Studio 2008 tools) I read out a normal display contents (Windows CE desktop), probably from the display buffer.
    In another topic

    Quote

    I read

    Quote

    Calling the command "boot display on" in NetDCU Config Utility makes the different. It was not necessary with the old modules but is required for the new ones.


    (1) Would that be the solution for my case?
    (2) What are "new", what are "old" modules? Can they be distinguished by their serial numbers on the top badge?


    I cannot find this command in NDCUCFG Version:042
    Is it documented anywhere?


    Regards


    André Lehmann

    How do I issue NDCUCFG commands from the DCUTermi window? From the debug output I see from
    "NDCUCFG V: 041 started. Platform: PicoCOM2"
    that NDCUCFG should be running on the remote system. But neither issuing a command nor transmitting a text file with NDCUCFG commands works.
    If I connect to the serial debug output using DCUTermi and press "S" while starting PicoCOM, I have a ":>" cursor, but not a "!>" cursor.
    The terminal program accepts EBoot commands such as "?" or "T".
    In the "First steps" document it is stated

    Quote

    !>
    If this command prompt appears in the terminal program you are
    ready to pass commands to NDCUCFG utility. Otherwise something
    went wrong. Please check various parameters described in chapter
    1.2.


    How do I change to this cursor? What may have gone wrong?


    Regards


    André Lehmann


    Addendum:
    I found out myself. I had to disable the serial debug output by calling "O" in the EBoot prompt. After reboot I now have the NDCUCFG prompt.

    Quote

    Do the PicoCOMs also show these exceptions if running on our Starerkit?


    Yes. The same two modules show exceptions while the same last one does not. Thus I would rule out my base board as being responsible for the failure state.
    How do I set an identical clean initial state on a PicoCOM module?
    Is it sufficient to use "NetDCU USB Loader" for writing NBoot, EBoot and kernel?
    How do I secure an identical initial registry contents?


    Can you provide me with a new adapter board to attach the Hitachi display (PicoCOM2_FirstSteps_eng.pdf, page 3, figure 2) to the starter kit? Due to frequent changing I broke the black lock at the connector.


    How do I issue NDCUCFG commands from the DCUTermi window? From the debug output I see from
    "NDCUCFG V: 041 started. Platform: PicoCOM2"
    that NDCUCFG should be running on the remote system. But neither issueing a command nor transmitting a text file with NDCUCFG commands works.

    Quote

    Does the exception still occure if removing USB cable?


    This is the debug output when there is no USB connection:


    There is still nothing displayed.

    Quote

    Are you running the PicoCOM2 on the starterkit or on a custom baseboard?


    On a custom baseboard. I have used the same type for months successfully. The other day one baseboard was damaged, so I had to use another one of the same type.

    Quote

    Have you tried to stablilze your power supply?


    Not so easy because the custom baseboard is delivered 12V 2.5A from a mains adapter, and the PicoCOM supply voltage is converted on the custom baseboard.


    How do I reset the contents of FFSDISK without repartitioning? I observe that settings such as the display mode remain unchanged after writing a new kernel to the module. Before that I always had to apply NDCUCFG commands to set the corrrect display parameters after updating the kernel.


    Quote

    I might not wonder if the display stays blank after the exceptions.


    I compared three PicoCOMs on the same base board.
    Two (PC1, PC2) show the stated exceptions, one (PC3) does not. The display remains dark in case of PC1, not for PC2 and PC3. In all modules the same display type is set.


    How can I issue NDCUCFG commands from the DCUTermi window?

    I updated NBoot and EBoot. The exceptions remain:


    If I use another PicoCOM2 module on the same mainboard (i.e. the same power supply), I receive the following debug output without exceptions:


    By the way, the attached display does not show anything though "Windows CE Remote Zoom-in" (a tool from Visual Studio 2008) reads a correct screen shot from the display buffer. What could be the reason for this?
    (The display module is OK as seen with another PicoCOM2 module on the same mainboard.)

    Hello,


    after setting up a new system I receive the following debug output while booting.
    As my application does not run properly I want to ask for explanation of the "exception" messages:


    Thank you in advance
    André Lehmann

    Can you comment on the following:
    Issuing the call

    Code
    1. b_success = DeviceIoControl(hDIO, IOCTL_DIO_REQUEST_IRQ, &dw_IRQ, sizeof(DWORD), NULL, 0, NULL, NULL);

    results in the debug output

    Code
    1. +OALIntrRequestSysIntr IRQ (254) already used by SYSINTR (18)


    Issuing the call

    Code
    1. b_success = DeviceIoControl(hDIO, IOCTL_DIO_RELEASE_IRQ, &dw_IRQ, sizeof(DWORD), NULL, 0, NULL, NULL ) ;

    results in the debug output

    Code
    1. +OEMInterruptDisable(24), irq: 254
    2. -OEMInterruptDisable


    Situation remains that

    Code
    1. b_success = DeviceIoControl(hDIO, IOCTL_DIO_WAIT_IRQ, &s_IRQStat, sizeof(s_IRQStat), &dw_WaitState, sizeof(dw_WaitState), NULL, NULL) ;

    always returns

    Code
    1. dw_WaitState != WAIT_OBJECT_0

    which means TimeOut though the line monitored for interrupts receives suitable state changes as seen by alternatively polling.


    All calls to DeviceIoControl() return non-zero.


    Thank you in advance for any hints


    André Lehmann

    Hello everybody,


    may I kindly ask to receive an answer?
    I suppose, at least the last two little questions can be answered with little effort.

    As this is the only means of communication (no phone service) I need your assistance.
    I cannot go on with my application before interrupt functionality is working.



    Thank you in advance


    André Lehmann