Part Number:AM5718
Tool/software: Linux
In our design (derived from but now significantly different than that of the AM5728 EVM), we have USB2 configured as a host talking to a WiFi radio which enumerates as a CDC ECM class device. As long as we don't put the processor to sleep, there are no issues. If we do go through a sleep/wake cycle, there are no detectable surface issues. Radio communications seemingly proceed just as they did before the sleep/wake cycle. However while chasing another issue, I'd enabled additional dynamic debug and discovered that after the sleep/wake cycle, there are repeated (every 96 ms) transfer errors. Again, note that these errors don't seem to affect the ability to communicate with the radio. Their biggest impact that we've been able to detect is wasted CPU cycles.
Doing
echo "module usbnet +p" > /sys/kernel/debug/dynamic_debug/control
I see the following repeated constantly and forever after a sleep/wake cycle
cdc_ether 1-1:1.0 eth0: intr status -71
The '-71' translates to EPROTO. If I further do
echo "module xhci_hcd +p" > /sys/kernel/debug/dynamic_debug/control
additional accompanying messages reveal that the reason for the protocol status report is
xhci-hcd xhci-hcd.0.auto: Transfer error on endpoint
which comes from handle_tx_event() in drivers/usb/host/xhci-ring.c.
I do see additional messages that show the code trying to recover from this, however the work is clearly ineffective as 96 ms later, the same thing happens again.
At this point, I run into a dead end as the Technical Reference Manual (SPRUHZ7H) does not have any information whatsoever on USB errors. In fact, the TRM explicitly states that there is insufficient information to design (and therefore) debug a Linux driver and that I must contact my sales rep to be able to obtain that documentation under an NDA. That is being pursued but will obviously take time. In the meantime, I thought I'd post the symptoms to see if this is a know issue.