• State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 21 subscribers
  • Views 3533 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

uLink - conflict with other USB HIDs?

Andy Neil

I have been having major grief with my uLink2 of late, rendering it virtually unusable!

:-(

I've had it about 4 months with just the usual occasional annoyances of lost comms - then it just went totally stupid!

I'm working with an STM32 target, downloading an AXF file.

After clicking the 'Load' button, I get the 'USB communication failure', or uVision will hang.

Other projects, and earlier versions of the same project, would work fine - it seemed to be something specific to the particular AXF file!

The same AXF file would work fine on another PC of mine, and my Client was able to use it OK - so then it looked like something funny with the particular Toshiba P300 Laptop.
But then, on a visit to the Client, it was fine on that Toshiba!

I have now just stumbled on something: it seems that the uLink2 behaves fine on the Toshiba provided I remove all other USB HIDs (mouse, keyboard)

So, has anyone else had similar troubles with a uLink2?

Or, if you are having trouble with your uLink2, have you tried disconnecting all other USB HIDs?

Do any of the USB experts here have any ideas what might be going on?

Sorry for the rambling, but it's been one of those issues...

Parents
  • 0 in reply to Andy Neil

    The uLink troubles teach us good lesson of robust USB implementation.

    a) On the host app, call USB Read / Write (such as ReadFile/WriteFile) asynchronously (OVERLAPPED). Even when the device hangs on the interrupt/bulk endpoint, your host app detects timeout, and cancels the call. To recover from hang, send a class request (for HID, Feature report), reset the hanged process on the device side.

    b) On the host app, detect surprise removal of the device using WM_DEVICECHANGE (RegisterDeviceNotification()). On surprised removal, close the USB device handle and kill the USB communication thread. Then, plugging off the USB cable recovers the hang without rebooting the PC. On the device side, bus-powered device like uLink2 gets reset by power-cycle.

    For the host app for HID, see Jan's implementation of WM_DEVICECHANGE.

    generic_hid_cs on The HID Page (http://www.lvr.com/hidpage.htm)
    www.lvr.com/.../generic_hid_cs_451.zip
    DeviceManagementDeclarations.cs
    DeviceManagement.cs

    Tsuneo

Reply
  • 0 in reply to Andy Neil

    The uLink troubles teach us good lesson of robust USB implementation.

    a) On the host app, call USB Read / Write (such as ReadFile/WriteFile) asynchronously (OVERLAPPED). Even when the device hangs on the interrupt/bulk endpoint, your host app detects timeout, and cancels the call. To recover from hang, send a class request (for HID, Feature report), reset the hanged process on the device side.

    b) On the host app, detect surprise removal of the device using WM_DEVICECHANGE (RegisterDeviceNotification()). On surprised removal, close the USB device handle and kill the USB communication thread. Then, plugging off the USB cable recovers the hang without rebooting the PC. On the device side, bus-powered device like uLink2 gets reset by power-cycle.

    For the host app for HID, see Jan's implementation of WM_DEVICECHANGE.

    generic_hid_cs on The HID Page (http://www.lvr.com/hidpage.htm)
    www.lvr.com/.../generic_hid_cs_451.zip
    DeviceManagementDeclarations.cs
    DeviceManagement.cs

    Tsuneo

Children