The datasheet says that after you put bytes in the endpoint’s FIFO and set TXPKTRDY to 1, you have to wait until the host ACKs the packet and TXPKTRDY goes to 0 again before writing another packet. TXPKTRDY is deasserted by the hardware when the host ACKs the packet at the same time as TXCOMP is set to 1.
It says that. However, what I’m seeing is different.
I poll TXPKTRDY to make sure it’s 0, I fill the FIFO, and set TXPKTRDY. The host gets the packet, and can even display its contents, which are correct. TXPKTRDY never returns to 0, though. And here’s the kicker. TXCOMP transitions as one would expect. TXPKTRDY just doesn’t do so at the same time.
I’m polling TXPKTRDY (not enabling the endpoint interrupt), as I’m trying to debug the problem, but the datasheet says nothing about having the interrupt enabled. It does, however, say that I cannot set TXPKTRDY to 1 again unless it is already 0, which it’s not, since it didn’t get reset when TXCOMP got set.
What’s up with that? Everything I recall seeing states that TXCOMP is set to 1 and TXPKTRDY is set to 0 by hardware when the packet is ACKed by the host. I recall no exceptions to this. This is a ping-pong endpoint, but the timing diagram for that in the datasheet still states that relationship quite clearly.
The datasheet I’m referring to is that of the AT91SAM7XC128/256/512, and the timing diagram is figure 33-8 in my copy of it. It is labeled “Data IN Transfer for Ping-pong Endpoint”. It might be numbered differently in a different version of the datasheet or in one for something else like the AT91SAM7S64.