Call dcd_event_xfer_complete on packet submit vs packet complete

[smunaut]

Hi,

I'm currently writing (well ... rewriting) a driver for a custom USB core used in several FPGA project and that's also being taped out in a ASIC soon ( https://github.com/no2fpga/no2usb ).

The hardware has support for dual packet buffer for the EPs and I'm wondering if there would be any ill-effect in reporting the transfer as being complete when I submitted the packets to the hardware, or if I have to wait for the hardware to report completion of the TX before doing so.

Cheers,

Sylvain

[hathach]

I think you should trigger the interrupt after packet complete i.e the data and CRC has been checked and/or ACK is being returned. Should something bad happened such as bad data toggle, incorrect checksum or more often STALLED response from host, it should report back to software. Depending on the class driver (stall may has different meaning for each class), tinyusb will decide to re-submit or abort the transfer.

[hathach]

Wait, if this is IN transaction, and we only submit the bytes to endpoint FIFO. There is still no guarantee that host will send any IN token any time soon. Would the hw trigger the transaction complete then. If yes, it could cause software to continue to submit more transfer, which could eventually cause buffer overflow since none has been sent to host.

One of the example would be CDC, device can try to printf() alot, but if host does not have any terminal connect to COM port. Host might not send any IN token at all.

[smunaut]

It's not really a fifo just a dual buffer descriptor. So it can't buffer more than 2 packets at most. If there is no space available, then ... data isn't queued and the xfer_complete() callback won't be called. It will only be called once there was space to queue the transfer in the hardware.

[smunaut]

(Also note that it's not really the hardware doing this, it's just the way I wrote the driver that calls the completion handler when it managed to successfully queue the data to the hardware rather than when the hardware itself reports the transmission of the packet)

[smunaut]

This is the driver in question and the specific place where I complete xfer once the buffer was submitted to HW :

https://github.com/no2fpga/no2usb/blob/master/fw/tinyusb/dcd_no2usb.c#L279

[hathach]

Then I think we should wait until transfer complete as mentioned above host may not send any IN token if there is no app (e.g terminal) requesting the data. Sure host has its own buffer but it may be full sooner or later. That will cause the new data dropped while old data is not consumed at all. Currently tinyusb stack will only queue 1 transfer per endpoint, double buffered is done at dcd level until all requested bytes (e.g 4k) is transferred (dcd complete) before queuing another transfer. Cannot queue an transfer on an not-busy endpoint is considered as error to the stack.