USB enumeration issue -- HOT!
Thread Summary
The user encountered an issue with newer PCs hanging during boot when a Blackfin ADSP-BF525-powered USB HID device is connected. The problem was traced to the 'Get Configuration' report, where the state machine in 'adi_usb_core.c' was not reset to Idle state. Adding a line of code to reset the state machine resolved the issue. The user was also advised to check if the host is re-enumerating USB devices and to consider updating to the latest VisualDSP++ 5.1.2 for potential fixes.AI Generated Content
Hello, not sure whether this is the right developer's thread but there you go anyway... in a nutshell we're working on a project involving a Blackfin-powered tethered device that communicates via the standard USB HID interface. The device is host-powered i.e. receives power from USB. The device has been deployed at multiple locations for 5+ years with no issues whatsoever. We recently discovered that some newer PCs hang at boot up when our device is permanently attached to (any of) the USB ports of the PC. If the device is physically disconnected while the PC is booting up and then re-attached to the PC then all is fine… but unfortunately this is not an acceptable workaround. We verified the issue is NOT related to insufficient power, and can be re-created at will even when the device is externally powered. We hooked up an USB analyzer and were able to trace the issue to the "Get Protocol" report; this is where the PC hangs. It seems like the USB stack is not responding properly to that packet and this 'upsets' the host PC. I'd be happy to share the trace if requested.
One step further, we've been single-stepping into the USB stack with an ADZS-USB-ICE emulator, and we suspect the 'HID_GetProtocol()' function might have a problem.
Is this a known issue?
Does anyone have a suggestion?
I pasted more details down below about the different versions being used in our project… is there a newer version of the stack we could use?
Thanks in advance!
Damien.
More details about our setup:
- Blackfin model: ADSP-BF525
- Development environment: VisualDSP++ 5.0 Update 6
- Host PC causing the issue: HP EliteDesk 800 G2
- Using the ADI USB stack.
- The 'HID_GetProtocol()' function belongs to file ‘usb_hid_keyboard.c' and contains the following header information:
/*********************************************************************************
Copyright(c) 2006 Analog Devices, Inc. All Rights Reserved.
This software is proprietary and confidential. By using this software you agree
to the terms of the associated Analog Devices License Agreement.
$RCSfile: adi_usb_bulkadi.c,v $
$Revision: 1.9 $
$Date: 2009/02/23 22:21:24 $
Description: Provides the custom ADI bulk class driver functionality.
*********************************************************************************/
- Note: we manufacture other similar devices that are based on other processors (e.g. ARM CortexM3) and use their vendor-provided USB stack and none of these has the issue described above. So far the issue is only with our Blackfin-powered devices.
Audio Signal Processors
adsp-bf525
usb enumeration issue -- hot!
Blackfin Embedded Processors
Hi Damien,
If the Blackfin processor state was in hibernate/power off, then re-enumeration is required as the controller loses its logic state because power is removed. https://ez.analog.com/thread/64671
So, if the Host is re-enumerating then it should be OK as the device would respond. Can you please confirm if the host is re-enumerating the USB devices attached to it ?
BTW, regarding the USB stack, there are many updates since Update 6 with the fixes to anomaly. The latest one is VDSP++ 5.1.2 and is available in the below link.
Regards
Guru
Thank you. We actually traced the issue to be in the handling of the "Get Configuration" report which in our scenario consistently occurs right before the "Get Protocol" report. The state machine in module "adi_usb_core.c" was not set back to Idle state after completion of the "Get Configuration" processing. We added one line of code and all went well, at least on our test machine. For the sake of this thread I'll share more details on what we exactly did once I get final assurance that the fix worked at our customer's.
This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.
Thank you,
EZ Admin
Please log in to reply.