imx25 USB interrupt endpoint packet never received after resuming from suspend

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

imx25 USB interrupt endpoint packet never received after resuming from suspend

1,863 Views
jamesledwith
Contributor I

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?

Labels (1)
Tags (3)
0 Kudos
9 Replies

1,439 Views
david_dicarlo
NXP Employee
NXP Employee

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.

0 Kudos

1,439 Views
david_dicarlo
NXP Employee
NXP Employee

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"

0 Kudos

1,438 Views
guerricbeaugran
Contributor I

Hello,

I am interested in the resolution of these two erreta . Concretely , how to solve the two problems ?

0 Kudos

1,439 Views
david_dicarlo
NXP Employee
NXP Employee

I am in the process of contacting that colleague to review this issue.  I will update you later this week.

0 Kudos

1,439 Views
guerricbeaugran
Contributor I

Do you have any news ?

0 Kudos

1,439 Views
david_dicarlo
NXP Employee
NXP Employee

CT raised: 45358105

0 Kudos

1,439 Views
jamesledwith
Contributor I

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).

0 Kudos

1,439 Views
fabio_estevam
NXP Employee
NXP Employee

Which OS are you using? If linux, can you try 3.16-rc2?

0 Kudos

1,439 Views
jamesledwith
Contributor I

Hello, we are not using Linux, we have a home grown OS.

0 Kudos