nRF52840 USB Cancel IN Transfer

[George Beckstien]

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:

1. OUT xfer - write a random payload to device endpoint
2. IN xfer - read back payload
3. Make sure data written and data read are the same
4. ...continue to loop...
5. OUT xfer - write a random payload to device endpoint
6. HALT IN endpoint
7. IN xfer - endpoint should reply STALL
8. CLEAR HALT on IN endpoint
9. OUT xfer - write a new random payload to device endpoint
10. IN xfer - read back payload
11. 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...

[Einar Thorsrud]

Hi,

I recommend you ask about this in the mbed forums, as you will probably get much better feedback on it there. (The mbed USB stack is not used in the nRF5 SDK, so we do not have much experience with it).

[George Beckstien]

Hi Einar,

I am actually working on contributing the USB implementation to Mbed-OS for the nRF52840. This is not an issue with Mbed. The issue is that the Nordic USB hardware does not present a clear way to cancel an auto-ACK on an IN endpoint after a DMA transfer has been completed.

The test only passes intermittently, presumably when the DMA transfer is fast enough to overwrite the old data before the new data is requested by the host.

Is there some way I can get support from Nordic in implementing the USB HAL for Mbed-OS? The implementation is very close to done, there are just a few more bugs to iron out.

Please let me know if there is a way I can converse with Nordic engineers via email.

Thank you

[Einar Thorsrud]

Hi George Beckstien,

I have asked masz from the SDK low level driver development team to help answering your questions in this thread.

[George Beckstien]

Ah! Mbed is currently using SDK14.2 and I only pulled in changes from 15.2 that were related to errata! I will go through the SDK15.2 driver and pull in other relevant changes... Mbed will eventually be transitioning to SDK15+ but it hasn't happened yet.

I figured it would be some sort of undocumented register manipulation.

Thank you masz and Einar! That should be exactly what I'm looking for. Hopefully it fixes this issue

[masz]

Consider switching to nrfx if you don't use SDK stack.

[George Beckstien]

I will certainly suggest that when Mbed-OS upgrades the Nordic SDK next.

[George Beckstien]

I merged in errata changes and workarounds from SDK15.3 to the nrf_drv_usbd.c used by Mbed-OS. I am still seeing the wrong packet being sent every now and then in this same situation.

What exactly does the workaround do in the nrfx_usbd_ep_abort() implementation you linked to? It does not seem to always "disarm" a "loaded" IN endpoint transfer.

I am running automated tests and 22 out of 100 iterations had a failure caused by this issue. This was on a hub that connected thru a dock thru thunderbolt 3. I am now testing with the DUT directly connected to my laptop and will let you know what the new results are.