I'm running into an issue with an iMX25 where an interrupt endpoint (EP number 7) is intermittently missing the first data packet after resuming from suspend.
The iMX25 device is being placed into selective suspend and the user is resuming the device by sending a data packet from the host to the device. The host then sends 4 setup packets: clear feature remote wakeup, clear feature endpoint 4 halt, clear feature endpoint 2 halt, and clear feature endpoint 4 halt. Then the OUT data packet is transmitted to endpoint 7 usually within 1ms of the last setup packet.
The data packet to endpoint 7 is intermittently lost. When it's lost, the device never receives an interrupt with the ENDPTCOMPLETE bit set for endpoint 7. USB traces that show the data packet was ACK'd but the device never received the data. I can confirm that endpoint 7 is still primed to read. I do receive an interrupt saying the handshake for endpoint 0's setup packet has completed.
When the data is not lost, I receive an interrupt with both endpoint 0 and 7 complete. Other times the endpoint 0 complete interrupt fires 1 ms before the endpoint 7 interrupt.
Has anyone run into a similar situation before? Is there anything that needs to be done while coming out of suspend to ensure all interrupt endpoints work properly?
I've also discussed this issue with a colleague. The impression he had was that the endpoint expects more data (one or more data packets to follow) and therefore no interrupt is fired. Check the buffers in memory and descriptors to see what's going on.
I have received the following from the module IP owner:
"Please check if below two errata are applied at customer's software.
The first errata is at imx25ce.pdf, and the second one is imx28's.
1. BID2053 USB: RX endpoint flush when receiving a token OUT
2. 2858 USB controller may access a wrong address for the dTD (endpoint transfer descriptor) and then hangs"
Hello,
I am interested in the resolution of these two erreta . Concretely , how to solve the two problems ?
I am in the process of contacting that colleague to review this issue. I will update you later this week.
Do you have any news ?
CT raised: 45358105
For additional information, according to the USB traces when the data packet is lost, and no interrupt was fired for Endpoint 7, the data packet was acknowledged with an ACK.
In the case where the data was received by the device and an interrupt was fired, the device responds with a NYET (not ACK).
Which OS are you using? If linux, can you try 3.16-rc2?
Hello, we are not using Linux, we have a home grown OS.