Hi,
I have a question about the C6748's USB0 periperal (but I expect the question equally applies to other processors that employ the MentorGraphics core).
After changing working code from using interrupt endpoints to bulk endpoints I am observing a problem. We are not using DMA and hence we rely on what has elsewhere been appropriately described as an "interrupt train" to transfer data on the IN endpoint. That is, we get an interrupt for USB0 indicating that the endpoint is ready for data, then we fill the endpoints FIFO with data and set TXPKTRDY in PERI_TXCSR. The hardware then transmits the packet over the USB and subsequently clears TXPKTRDY. In accordance with the documentation [sprufm9h.pdf], the clearing of the TXPKTRDY generates another interrupt and the process repeats itself.
The problem we are experiencing is that at some seemingly non-deterministic time (after many packets have successfully been transferred) the "interrupt train" grinds to a halt. The TXPKTRDY is cleared but no interrupt is received. If we subsequently set the TXPKTRDY bit an interrupt is fired.
The documentation [sprufm9h.pdf] says the following about TXPKTRDY: "Set this bit after loading a data packet into the FIFO. It is cleared automatically when a data packet has been transmitted. An interrupt is generated (if enabled) when the bit is cleared."
The "(if enabled)" part is a bit ambiguous but to my understanding the state of play is this: I have enabled interrupts but occasionally I do not get an interrupt. I would appreciate it if someone -- perhaps TI or MentorGraphics -- could clarify under which circumstances I may not receive an interrupt.
Kind regards,
Mark