IMXRT1170 USB Host Enumeration Failure

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

IMXRT1170 USB Host Enumeration Failure

Jump to solution
895 Views
bobbyjones0
Contributor II

Summary:

I'm currently investigating a failure to enumerate issue when using the IMXRT1170-EVK as a USB host and connecting to a custom USB device.

Context:

On the EVK side, I'm using the "evkmimxrt1170_host_hid_generic_freertos_cm7" example provided from the 2.13.1 SDK. I am using the USB1 connector as described in the example documentation, and am providing 5V to the connector by bridging J25.10 (+5V rail) to J38.3 (5V_USB_OTG1). The custom USB device is implementing a "vendor specific" USB 2.0 device with some fairly simple in/out endpoints. When initially setting this up, I expected to get a "device not supported." message as this is not a standard HID device, but I only ever saw "enumeration failed" messages which indicated a failure before the device class was even checked.

I verified the EVK side set up by connecting another EVK running the "evkmimxrt1170_dev_hid_generic_freertos_cm7" example, as well as some other standard HID devices like a mouse. All of these configurations worked as expected. Furthermore, connecting the custom USB device to my workstation results in successful enumeration and I am able to see all expected pid/vid/etc descriptor content.

Initial debug efforts showed that the "eventCode" provided to the application callback "USB_HostEvent" function is consistently a value of "0xb0005" indicating that the enumeration failed due to a "kStatus_USB_TransferFailed" error. Tracing the function calls back I see that the very first transaction qTD status shows a "babble" error. I believe this babble error to be the primary reason the enumeration process is unsuccessful.

My research shows that the host controller experiences a babble error when it receives more bytes than expected from the device. After numerous attempts at manipulating config headers, application code, library code, and host controller registers, I have been unsuccessful in affecting this experienced babble error.

Output:

Below is the output of some added printf's I added while debugging. They may or may not provide some relevant information.

Spoiler
host init done
USB_HostEhciTaskFunction(): bitSet=0x8 - PORT CHANGE
USB_HostEhciTaskFunction(): bitSet=0x9 - PORT CHANGE
USB_HostEhciTaskFunction(): bitSet=0x9 - DEVICE ATTACHED
USB_HostAttachDevice(): speed=0x2, hubNumber=0x0, portNumber=0x0, level=0x1
newInstance=83001810
newInstance->deviceDescriptor=83001990, newInstance->enumBuffer=830019A2
Returning kStatus_USB_Success=0
USB_HostEhciTaskFunction(): bitSet=0x2 - TRANSACTION DONE
transactionDone(): pipeType=0, USBSTS=c080
TRANSFER = 0x12 0x1 0x0 0x2 0xff 0x0 0x0 0x40
transactionDone(): transferResults=80008080
transactionDone(): transferOverlayResults=80080150
transactionDone():ERROR qtdStatus=50
transferSofar=0x8. transferLength = 8.
transferSofar=0x0. transferLength = 8.
USB_HostEnumerationTransferCallback(): status=11,dataLength=0
kStatus_USB_TransferFailed!
USB_HostEhciTaskFunction(): bitSet=0x2 - TRANSACTION DONE
transactionDone(): pipeType=0, USBSTS=c080
TRANSFER = 0x12 0x1 0x0 0x2 0xff 0x0 0x0 0x40
transactionDone(): transferResults=80008080
transactionDone(): transferOverlayResults=80080150
transactionDone():ERROR qtdStatus=50
transferSofar=0x8. transferLength = 8.
transferSofar=0x0. transferLength = 8.
USB_HostEnumerationTransferCallback(): status=11,dataLength=0
kStatus_USB_TransferFailed!
Device No Response
eventCode=0xb0005.
enumeration failed

Related Questions:

  1. What is the purpose of requesting only 8 bytes in the default "kStatus_DEV_GetDes8" cases?
  2. Why when changing to "kStatus_DEV_GetDes" and requesting the full descriptor do I still only see 8 bytes worth of data in the transfer buffer?
  3. Where in this example code is the right place to make modifications the the USB host controller registers such as "USBMODE/PORTSC1/TXFILLTUNING"?
  4. The example's "usb_host_config.h" describes "USB_HOST_CONFIG_KHCI/USB_HOST_CONFIG_OHCI" symbols but turning them on introduces compiler errors as the associated headers can not be found. I can't seem to find them anywhere in the SDK either.
  5. EDIT: Is there any issues with clearing the babble error from the qTD overlay structure and just continuing on?

I'll admit I'm a novice with the USB spec, any suggestions or debugging tips are very welcome. 

iMXRT1170 

0 Kudos
1 Solution
789 Views
bobbyjones0
Contributor II

I tried that demo already, it did not affect the behavior.

We purchased a protocol analyzer, but discovered the source of the problem before it arrived!

The custom device apparently does not support an 8 byte descriptor transaction. It would instead send it's full descriptor, which caused the babble error. We changed the USB library's enumeration stage to allow for the full 18 byte descriptor and things work perfectly.

Diff of required changes:

 

 

diff ./MODIFIED/usb/host/usb_host_devices.c ./ORIGINAL/usb/host/usb_host_devices.c
332a333,336
>             if (deviceInstance->state == (uint8_t)kStatus_DEV_GetDes8)
>             {
>                 getDescriptorParam.descriptorLength = 8U;
>             }
413,414c417,418
<         case kStatus_DEV_GetDes8: /* process get 18 bytes descriptor result */
<             if (dataLength != 18u)
---
>         case kStatus_DEV_GetDes8: /* process get 8 bytes descriptor result */
>             if (dataLength != 8u)
1157c1161
<     pipeInit.maxPacketSize   = 18U;
---
>     pipeInit.maxPacketSize   = 8;

 

 

View solution in original post

0 Kudos
4 Replies
840 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi,

From the issue description, you have two RT1170 EVK boards with same example code and same jumpers setting. One can work with a customer USB device, the other one can not. The problemed EVK board even could not pass the  USB enumeration progress.

Is my understanding correct?

If both boards with same hardware design version number?

You could get related info from board surface stickers start with "SCH-" & "700-".

Thanks for the info.

Mike

0 Kudos
833 Views
bobbyjones0
Contributor II

Hi! Thank you for the reply.

To answer your question: The values are "SCH-32171 REV C4" and "700-32171 REV A1".

However, your understanding isn't quite right. I have two EVK boards, but neither will enumerate the customer USB device. They DO enumerate to each other when programmed with the complimenting USB host/device SDK examples. Only my workstation will enumerate the customer USB device (tested on both Ubuntu 22.04 and Windows 10).

0 Kudos
802 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi,

Thank you for the correction.

Could you please try the SDK demo "host_hid_generic_bm_cm7" with that customer device? Same result?

If possible, if you have USB protocol analyzer tool on hand, please help to capture the communication data during the USB enumeration process.

Then we could check what happened during USB device enumeration.  Thanks.

best regards,

Mike

0 Kudos
790 Views
bobbyjones0
Contributor II

I tried that demo already, it did not affect the behavior.

We purchased a protocol analyzer, but discovered the source of the problem before it arrived!

The custom device apparently does not support an 8 byte descriptor transaction. It would instead send it's full descriptor, which caused the babble error. We changed the USB library's enumeration stage to allow for the full 18 byte descriptor and things work perfectly.

Diff of required changes:

 

 

diff ./MODIFIED/usb/host/usb_host_devices.c ./ORIGINAL/usb/host/usb_host_devices.c
332a333,336
>             if (deviceInstance->state == (uint8_t)kStatus_DEV_GetDes8)
>             {
>                 getDescriptorParam.descriptorLength = 8U;
>             }
413,414c417,418
<         case kStatus_DEV_GetDes8: /* process get 18 bytes descriptor result */
<             if (dataLength != 18u)
---
>         case kStatus_DEV_GetDes8: /* process get 8 bytes descriptor result */
>             if (dataLength != 8u)
1157c1161
<     pipeInit.maxPacketSize   = 18U;
---
>     pipeInit.maxPacketSize   = 8;

 

 

0 Kudos