• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 99 subscribers
  • Views 4235 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ActiveSync not getting connected

Gomathi Chan
Intellectual 535 points
Other Parts Discussed in Thread: AM3358

I'm using AM335x Beagle Bone black with WinCE 7 BSP VS 2008 on a Windows 7 PC. I'm using Mobile Device Centre. When the device boots, I'm getting '**USB device not recognized**' pop-up message. I have checked the following.

1. Required catalog items have been added
2. All the USB drivers are in final image
3. Tested it in windows XP 32-bit PC - error persists
4. All the USB drivers are getting loaded
5. Checked for mobile device-based updates in PC

The catalog items I have added are,

1. Core OS\Windows Embedded Compact\Device Drivers\USB\USB Function\USB
Function Clients\USBFN Serial Client
2. Core OS\Windows Embedded Compact\Device Drivers\USB\USB Function\USB
Function Support
3. Core OS\Windows Embedded Compact\Applications - End User\Active
Sync\File Sync
4. Core OS\Windows Embedded Compact\Applications - End User\Active Sync
5. Core OS\Windows Embedded Compact\Shell and User
Interface\Shell\Graphical Shell\Standard Shell
6. Third Party\BSP\AM33X_BSP\ARMV7\Drivers\MUSB OTG Driver

Am I missing any catalog item? What else can I verify for ActiveSync connection?

The registry values in the final image NK.bin include

[HKEY_LOCAL_MACHINE\Drivers\USB\FunctionDrivers]

"DefaultClientDriver"="Serial_Class"

[HKEY_LOCAL_MACHINE\Drivers\USB\FunctionDrivers\Serial_Class]

"idVendor"=dword:045E

"idProduct"=dword:00ce

"Manufacturer"="Texas Instruments"

"Product"="AM33x"

"DevConfig"=hex:10,00,00,00,78,00,00,00,00,01,00,00,00,4e,00,00,00,00,08,00,00,00,00,00,00

"Index"=dword:5

[HKEY_LOCAL_MACHINE\Drivers\USB\FunctionDrivers\Serial_Class\Config]

"EnableFlowHard"=dword:0

"EnableFlowSoft"=dword:0

Thanks.

  • 0
    Expert 1450 points

    Gomathi,


    Everything looks correct, I think your next step should be to verify that the ActiveSync function driver (serialusbfn.dll) gets loaded when you connect the board to your PC. You could use the kernel debugger for this, and also to look out for any interesting debug messages.

    If everything is as expected at this point I would take a look at the bus activity using either a USB analyzer or, if you don't have that available, a packet sniffer application on the PC.

    If you had been using a custom hardware design I would have also suggested verifying that the USB hardware was working, for instance by substituting the ActiveSync function driver with the storage driver, which should allow any host device to detect your board as a mass storage device. Since this is the Beagle Bone Black I will assume that the hardware is OK.

    Best regards,
    Carsten

  • 0 in reply to Carsten Hansen
    Intellectual 535 points

    Thanks. I'm building my BSP in debug mode only. So, when I observed the logs, I found that serialusbfn.dll is not getting loaded. How to get it loaded?

  • 0 in reply to Gomathi Chan
    Intellectual 610 points

    I cannot say for certain right now, but I know using the Adeneo Windows Embedded COmpact 7 BSP for the AM3358 processor we are using, that ActiveSync does not work for us in a Debug build. Have you tried it in a Release build?

    Something in my head from me working on my project for some time now is telling me that you can't have KITL and ActiveSync at the same time but I might be wrong. If the Release build works, try disabling KITL in your Debug build and see if ActiveSync works in that.

    I might be totally wrong, but something to try.

    Cheers

    John

  • 0 in reply to John Reid
    Intellectual 535 points

    Hi John,

    You were right! In release mode, it connects fine! I disabled KITL and tried. In debug mode, I was trying with disabled KITL only. But, didn't work. Got any idea why it fails in debug mode?

    Thanks,

    Gomathi

  • 0 in reply to Gomathi Chan
    Expert 1450 points

    Hi Gomathi,

    USB is sensitive to timing, so it is possible that debug messages, debugger traffic etc. could have disrupted USB communications. Or perhaps try a checked build and see if that works? (A checked build is like a debug build, but with compiler optimizations enabled).

    When you say you disabled KITL do you mean you did that at runtime in the Eboot menu or at compile time in the project properties? If at runtime, it might be a simple coding error - check the OALKitlInitRegistry function for instance. In our BSP this function modifies the registry contents to enable/disable the normal LAN and/or USB drivers depending on whether KITL is active or not.

  • 0 in reply to Carsten Hansen
    Intellectual 535 points

    Hi Carsten,

    Thanks for the details about debug mode and USB.  I disabled KITL during runtime in the Eboot menu. KITL gets disabled properly in both debug and release mode. In debug mode, the ActiveSync connection alone is not happening. I think the reason you suggested is very valid. But, is there any way KITL can be kept enabled and Active sync still has to get connected in Release mode? Why they are conflicting?

  • 0 in reply to Gomathi Chan
    Intellectual 610 points

    Cool, am glad I wasn't making stuff up then :-) .

    I would try disabling it through the build option in your Debug or as Carsten suggests the Checked build.

    I think it is more to do with USB than ActiveSync specifically.  Try plug a mouse (may need some Adaptor) in to the same port using the same Debug configuration/build where ActiveSync wasn't working, and see if the mouse works.

    This text is taken from the WinCE-BSP ARM-A8 User Guide and could be a reason:

    "It is critical that all USB drivers be disabled when USB RNDIS KITL is in
    use. The USB RNDIS KITL implementation automatically disables the standard USB drivers when KITL is active."

    It is not something I have tried to resolve and I just use a Release build for doing ActiveSync activities.

    Cheers

    John

  • 0 in reply to John Reid
    Expert 1450 points

    Gomathi,

    Can you clarify if you are using KITL with USB/RNDIS or LAN?

    I had assumed you were using a LAN connection, but John is absolutely correct that if you are using USB RNDIS then no other function drivers will be working at the same time. And that's a design issue - not a bug as such - so would be hard to "fix".

  • 0 in reply to John Reid
    Intellectual 535 points

    Hi John,

    Thanks for that explanation. As I understood, the USB OTG, which is now used for Active Sync is used for KITL also. So, KITL and Active Sync can't be used at the same time due to the reason mentioned in the text you shared. Am I correct about that?

    Also, I found that I haven't included the catalog item

    Core OS\Windows Embedded Compact\Device Drivers\USB\USB Function\USB Function Clients\USBFN RNDIS Client

    What does it interpret? Should I include it for KITL?

  • 0 in reply to Carsten Hansen
    Intellectual 535 points

    Hi Carsten,

    I didn't give any Ethernet connection  to the device. So, I suppose it is USB RNDIS. 

    Thanks,

    Gomathi

  • 0 in reply to Gomathi Chan
    Expert 1450 points

    Hi Gomathi,

    Well that explains it :O)

    It is just not possible to use any other USB function driver (such as ActiveSync, the mass storage class driver, etc) while the USB RNDIS KITL driver is active. The KITL driver is a very low-level piece of code that only interfaces with the KITL library in the kernel, and takes complete control of the USB hardware.

    If you do need to debug the USB stack at any point, you could set up a KITL connection over LAN instead - that should allow you to have a USB ActiveSync connection whilst at the same time use the kernel debugger via LAN.

    The USB RNDIS Client in the catalog is just a normal WinCE driver, which you don't need for ActiveSync or KITL/debugging. It supports a Microsoft protocol that essentially allows you to use sockets to communicate over USB. So your device and the connected USB host would get IP addresses assigned, and could then use socket(), connect(), send() and recv() the way you would normally do on a network like Ethernet. I could be wrong but I think RNDIS host drivers only exist for Windows.

    Cheers,
    Carsten

  • 0 in reply to Gomathi Chan
    Intellectual 610 points

    I just came across an article I had bookmarked ages ago:

    http://social.technet.microsoft.com/wiki/contents/articles/3166.preventing-usb-and-kitl-conflicts-windows-embedded-compact-7.aspx

    which might be related to your issue also.

    Cheers

    John

  • 0 in reply to John Reid
    Intellectual 535 points

    Hi John,

    Thank you so much for that article. It was very informative. I too have bookmarked it now. Thanks a lot!

    Regards,

    Gomathi