I am working on the Mbed-OS HAL implementation for the nRF52840 USB device.
I have it almost passing all the automated tests. One where it fails is when the Mbed test suite attempts to halt an endpoint.
Essentially the test works like this:
- OUT xfer - write a random payload to device endpoint
- IN xfer - read back payload
- Make sure data written and data read are the same
- ...continue to loop...
- OUT xfer - write a random payload to device endpoint
- HALT IN endpoint
- IN xfer - endpoint should reply STALL
- CLEAR HALT on IN endpoint
- OUT xfer - write a new random payload to device endpoint
- IN xfer - read back payload
- Make sure the new random payload and the data read are the same
The failure occurs because the Mbed stack immediately loads the payload received during the OUT stage into EasyDMA and begins the transfer for the corresponding IN endpoint. Then the endpoint is halted, it replies STALL as expected. But when the HALT is cleared, the hardware is still prepared to ACK the next IN transfer that begins on that endpoint. It will then respond with the old payload -- causing the test to fail.
This happens more often than not, but sometimes the test does pass.
I have attached a screenshot of the captured USB traffic during this failure.
Is there a way to clear the USB hardware readiness state for an IN endpoint after an EasyDMA transfer has been completed on it? I have tried disabling and reenabling the endpoint and the issue still occurs. It seems as though the USB hardware should allow this kind of operation...
