USB hub issues with MXRT1064EVK

[maxkunes]

Both the NXP SDK and USBX have issues with many USB hubs on the MXRT platform. After lots of investigation, I was able to at least somewhat get the NXP SDK examples to consistently enumerate and communicate with all devices on a hub by increasing the hub port reset delay. However, the NXP USB drivers tend to have other issues that makes me not want to use them compared to USBX.

I've tested USBX with USB hubs to connect a mouse and keyboard to a single port without luck so far. USBX always enumerates the hub but fails to enumerate any devices on the hub. I get a USBX error callback due to a transaction not getting a response that is triggered by the stack trying to set an address of a device on the hub after that device's port has been reset.

I am unfortunately unable to provide much more information than this as I do not have access to a USB protocol analyzer at the moment.

[xiaocq2001]

Thanks for the feedback.

Based on USB spec. if a low-speed (LS) device (usually HID devices are low speed) are connected to a high-speed (HS) port through a high-speed hub, the operations on that device needs special way of transfer, the split transfer, the split-transfer sent to high-speed hub is translated to full speed (FS) or LS transfer. I think that's possible your case. The host is sending high-speed set address request to the device but not split transfer set_address, so device is not able to recognize the request and there is no response.

If there is a full speed port, please use full speed port for hub with HIDs.

The possible workaround for high speed port.

1. Directly connect HID devices to the port and see if they work to confirm the port can work in FS/LS mode.
2. Connect a full speed hub to the port to force the port sends FS signal to the hub.
3. Connect HIDs to the full speed hub downstream port to check if they works.

[maxkunes]

@xiaocq2001

Thanks for the quick response. Would you then consider this to be a USBX bug? This sounds like something the stack should handle.

One thing is that NXP's example works. I notice that in the phy_init code that is used by both USBX and the NXP example I see this: usbPhyBase->CTRL |= USBPHY_CTRL_SET_ENUTMILEVEL2_MASK; /* support LS device. */ usbPhyBase->CTRL |= USBPHY_CTRL_SET_ENUTMILEVEL3_MASK; /* support external FS Hub with LS device connected. */

It seems like these settings should make what I'm doing work, right? However, as I said, USBX init code uses this and I still have problems.

I think you might have suggested that forcing the USB interface to be full speed might help, is this correct?

[maxkunes]

So I got everything working which is great. All I had to do is force the USB PHY to full-speed mode instead of high-speed as you suggested.

Atleast on MXRT, the timing of when you set the force full speed register is important. So I ended up modifying ux_hcd_ehci_initialize.c to call an extern function in my main application. I made this call happen after the global reset and right under UX_HCD_EHCI_EXT_USB_HOST_MODE_ENABLE(hcd_ehci);. The function that forces fullspeed is below in-case anyone wants it.

void force_fullspeed_usb() {
    // USB1 is the port closest to the eth port on the MIMXRT1064EVK board.
    // ideally this function takes the hcd_ehci value from the caller and computes the correct peripheral pointer from that.
    USB1->PORTSC1 |= USB_PORTSC1_PFSC(1);
}

Again, this seems like something that USBX should handle. Because now I wouldn't be able to fully utilize a device that runs in high-speed mode on the hub. This will work for me though.

[xiaocq2001]

Good to here your things working.

Thanks for the feedback and we will keep improving USBX.

[maxkunes]

@xiaocq2001 Again, can I get clarification if this is something that USBX intends to support out of the box? Thank you for your support though.

[xiaocq2001]

Thanks Maxkunes. We will support this in future releases.

[yuxin-azrtos]

Close.