Hi,
I already posted my questions in a different topic, but I've got no answer to it, so I try to ask it here.
How teardown mechanism working exactly? At the moment I do teardown in the following way:
1. The teardown queue is set to 30 in CPPI_TDFDQ register
2. A teardown descriptor is added to the teardown queue.
3. When a channel teardown is initiated teardown flag is set in TX/RX GCR with complete queue ( it is EP and direction dependent ) For example for USB0 TX EP2 queue 94 is used
4. EP teardown bit is set in USB_TRDWN register
5. Complete queue ( in this example 94 ) is polled for teardown descriptor. Until a descriptor is present go back to point 4.
6. Teardown bit is set again.
7. TX/RX GCR teardown flag is cleared.
Is this okay? Because my problem is for example when an RX transfer is started on EP1 ( queue 0 is used for it ) and there is a channel teardown because of device disconnection than the queued descriptor will remain in the RX/Free descriptor queue (0), however the teardown is initiated and the teardown descriptor is given back into the complete queue by the HW. What should the SW do to get rid of this queued RX descriptor? Do the SW needs this dedicated teardown queue ( 30 )? Or it should just set the teardown queue to the number of the channel queue ( 0 ) which is shut down?
GRNDIS bug or feature?
In device mode GRNDIS transfer is not working correctly in RX (OUT) direction.
For example: The application is a CDC-serial device and uses a self protocol to test CDC IN and OUT speed. The device receive transfer settings are: Buffer size: 2k, Transfer size 2k, RX mode is GRNDIS, EP3 is used, RX submit queue number is 3, completion queue is 111. Transfer length is 2k*1k.
So it is a simple situation. Sometimes it is working correctly. However sometimes the device got an interrupt after some 2k packets with a length of 64/128 bytes data instead of 2k and sometimes there is no interrupt after 2k received. It depends on how I enable/disable DMA for that EP. I checked the USB bus, the packets are there and they are correct. The host is a PC.
Locked queue?
Sometimes there is a situation when EP3 queue is freeze. The descriptor is not in the RX submit queue, but it is not in the completion queue also. So the DMA still processing that descriptor. However this channel couldn’t be torn down. I pull out and plug in the USB cable again and in this case the SW tear down all active transfers, but when the test is started again there is nothing. No interrupt and no descriptor. So I assume that descriptor is still being locked by the DMA. Is there a way to reset CPPI?
64/128 byte bug:
When the CPPI interrupt is after 64bytes in the receive buffer I see that 64bytes only, however on the USB bus the whole 2k is present with ACK, so the HW received and ACK-d those packages. In this case I checked the next interrupt and I saw that the transfer length is correct now, however the first 1984 bytes are the bytes from the previous transfer and only the last 64 bytes are from the last package. So somehow the transfer is shifted and the HW received the 2k, but the DMA only transferred 64bytes and indicated a transfer end interrupt. And in the next transfer the remaining data is completed to 2k with the next packet first 64bytes. So in the end the last 64 bytes of the last packet is never received.
This happens only if the DMAenable bit is always set in the MUSB_RXCSRI register. If this bit only set when a descriptor is pushed into the queue than sometimes the interrupt is not generated for an ACKED package.
What am I doing wrong?
Thank you in advance!