Hi guys,
we are finally finished with imlementing a larger application also providing headless USB drive audio playback functionality on our own PCB. Recently produced devices now surprisingly show an issue of not reliably enumerating a plugged USB flash drive anymore, making USB controller to enter a "locked" state (meaning it does no longer react on any attach/detach attempts until reboot).
Our application runs on FreeRTOS, implementing the SDK-prodvided USB stack (using SDK v2.4.2). The application basically runs in external SDRAM (loading binary from SPI NOR during startup). The RTOS heap is also placed into SDRAM. In the past we've observed erroneous data transfers from/to USB controller which were solved by setting USB_HOST_CONFIG_BUFFER_PROPERTY_CACHEABLE switch in usb_host_config.h, enabling additional code within USB stack to flush appropriate cache lines at certain code locations for interaction with USB controller.
Some devices now do not enumerate a plugged USB device reliably anymore (they only do sporadically). I debugged the "attach" flow within USB stack and figured out that the enumeration gets stuck at the first interaction with the plugged USB device. When plugging the device I see two "PORT_CHANGE" events sent by Interrupt handler and one "DEVICE_ATTACHED" that is sent while handling the PORT_CHANGE events in USB_HostEhciPortChange().
When handling the attached event the USB task function steps into USB_HostAttachDevice() function finally entering USB_HostProcessState(). The enumeration state machine starts at this point with state "kStatus_DEV_GetDes8" requesting some first information from USB device. If the enumeration is working there are lots of TRANSACTION_DONE events stepping through the whole state machine until it finishes. If it does not work I only see the "System Error Interrupt" (SEI) bit set in interrupt status register (USBSTS) followed by cyclic TIMER0 interrupts of the USB controller. Unfortunately there only is a very poor documentation about the individual status bit's meaning (especially this SEI bit) in RT1050 reference manual.
So currently I got stuck in further debugging this issue. For testing purposes I loaded the SDK USB example "host_msd_fatfs_bm" into some devices. Curiously this tiny example worked well. So I don't assume the issue being HW related. But I think the SEI bit might be an interesting trace that is worth to follow. So what makes the USB controller setting this bit?
Regards
André
