none
USB Devices are not Recognized in the mini2440/FriendlyARM board operating Wn CE 6.0 RRS feed

  • Question

  • Hi,

    I have the following urgent question. We are trying to interface our USB-based devices to the mini2440/FriendlyARM

    board running Win CE 6.0. But our devices are not recognized by the mini2440 board (Win CE 6.0).

    We put an USB traffic analyzer to investigate what is happening and we think the following might be an
    explanation why our devices are not recognized.  When the USB bus is negotiating to get a descriptor from the
    slave device, it sends a request for 8 bytes in WinCE and 64 bytes in Linux (and Window) environment.  Our
    device does not look at the length field and always send 18 bytes as a response.  Since WinCE kernel appears
    to allocate 8 bytes for response data, it is possible that the 18-byte response might crash the kernel and as
    a consequence we do not see anything happening.  (Normally a dialog box will pop up requesting for the USB dll-
    assuming that the registry does not contain an entry corresponding to the vendor id/product id and/or USB device
    classification).

    Unfortunately we cannot fix our device (since there are too many already sold) and we have to fix the way WinCE
    gets the descriptors.  It would be helpful it one can point out which modules are used in the kernel (like USBD.dll)
    and the corresponding source code.  Also RETAILMSGs do not appear on the serial port attached to the box.  We tried
    to compile a debug version (which we did after many hours of trying but there seems to be a problem loading a 42
    Mbyte kernel (though we used the option of loading kernel bigger than 32 Mbytes).  If we have some kind of messages
    coming out of the box, we can debug the code ourselves to an extent.


    Any help in fixing this problem of not recognizing our USB devices will be greatly appreciated.

    Thanks,

       Paul

    Thursday, May 27, 2010 5:47 PM

Answers

  • Thank you all,

    We solved the problem with changing the expected back descriptor data size in our devices USB driver.

    Best regards,

       Paul

    • Marked as answer by Paul Tomov Tuesday, June 15, 2010 8:21 PM
    Tuesday, June 15, 2010 8:21 PM

All replies

  • You may need to modify the USB host controller driver.
    When a device is attached, the HCD first get the descriptor and then notifies USBD by calling its HcdDeviceAttached.
    Since you probably not use standard USB host controller, you will need tracing the HCD driver to figure out how it issue an USB_DEVICE_DESCRIPTOR_TYPE command.

    And for your reference, in standard HCD drivers, the USB_DEVICE_DESCRIPTOR_TYPE is issued by GetDescriptor which is invoked by CHub::AttachDevice.
    There is a state machine in CHub::AttachDevice that calls GetDescriptor (with USB_DEVICE_DESCRIPTOR_TYPE) 3 times, the first 2 are issued with packet size as ENDPOINT_ZERO_MIN_MAXPACKET_SIZE (8 bytes) for initialization and only get the full descriptor in 3rd call.

    For detail please refer to following code
    public\common\oak\drivers\usb\hcd\COMMON\cdevice.cpp
    public\common\oak\drivers\usb\hcd\USB20\USB2COM\cdevice.cpp

     

    Friday, May 28, 2010 6:08 AM
  • We tried to compile a debug version (which we did after many hours of trying but there seems to be a problem loading a 42

    Mbyte kernel (though we used the option of loading kernel bigger than 32 Mbytes).  If we have some kind of messages
    coming out of the box, we can debug the code ourselves to an extent.

    When you a do a debug build, it takes up alot more space, you may need to adjust your memory map or where certain memory buffers are located.

    I would look at your config.bib and look at your Memory Map to ensure that with your new larger OS Image that you are not over-running the area allocated for your OS Image.  It is possible that the entry is not set to automatically re-size the image, or it is also possible that it is now big enough now that you are over-running other regions that you had reserved for memory buffers.

    As per not getting any RETAILMSGs are you running a SHIP or RETAIL build?  In a SHIP build all RETAILMSG are actually compiled out and you will need to use NKDbgPrintfW.  Do you get anything out your debug port at all that tells you at what stage the debug build is failing?

    Hope this helps,

    Brad.

    Friday, June 4, 2010 4:43 PM
  • Thank you all,

    We solved the problem with changing the expected back descriptor data size in our devices USB driver.

    Best regards,

       Paul

    • Marked as answer by Paul Tomov Tuesday, June 15, 2010 8:21 PM
    Tuesday, June 15, 2010 8:21 PM