IN endpoint gets stuck during USB suspend
Despite all my efforts to fix #4251, I still coulf find situations where the number of alloccated buffers would grow. Even more so, after stopping the simtrace2-remsim-client program for some time and later re-starting it, the pending transfers from before would not get delivered.It took me many hours of debugging. What appears to happen is the following sequence of events:
- the firmware writes the first entry of the IN endpoint transmit queue to the USB device peripheral (UDP) of the SAM3S
- the host is currently not scheduling any IN transfers as the libusb-using application is stopped and hence there are no URBs for that IN endpoint
- the host application is restarted at some point (and obviously sends IN tokens again)
- the pending transfer never completes, which in turn blocks all the further entries of the endpoint transmit queue.
- it actually deactivates the USB transceiver and the peripheral clock to the USB device
- it doesn't call any pending callbacks for the ongoing transfers (not even calling them with state=error)
- it doesn't block any further calls to the USB peripheral, such as USBD_Write() calls that will happily [think they] modify the registers of the USB peripheral
The main problem seems to center around the call to
USBD_HAL_Suspend(). If I comment-out that call, IN transfers continue happily after the USB Resume.