nRF54LM20A USB Device: Endpoint 0 fails to ACK zero-length GET_DESCRIPTOR requests

[Ozzy]

Hi everyone,
I recently encountered an issue while developing with the nRF54LM20A. When acting as a USB High-Speed (HS) HID mouse device, Endpoint 0 fails to respond with an OUT ACK when the PC host sends requests with wLength = 0x00 (this includes but is not limited to the command: 0x80 0x06 0x00 0x06 0x00 0x00 0x00 0x00).
My workaround with other USB chips was to directly configure an OUT ACK when detecting a GET_DESCRIPTOR request with wLength = 0x00, which complies with the USB specification. However, I couldn't find the corresponding API/interface to achieve this on NCS.

Below is the USB data when the length is non-zero; Endpoint 0 behaves normally.(n54LM20A)

Below is the USB data when the length is zero; the Endpoint 0 OUT status is abnormal.(n54LM20A)

Below is the data captured using another vendor's IC, where Endpoint 0 responds correctly with zero-length requests. (Note: This IC has been mass-produced in our nRF54L15-based products.)

Could anyone advise on how to resolve this issue?
PS: I'm using NCS v3.1.1, and this issue can be reproduced with the USB HID mouse example.

ozzy

[Hung Bui]

Hi Ozzy, 

We want to know which USB chip/IP used on the Windows PC that you used. You can look at the Device Manager:

Then you can look at the details and send us your screenshot like this: 


If you can't find that, you can also send the mother board name and part number we can try to find relevant information from that. 

[Ozzy]

Hi Hung Bui,

Following your instructions I located the relevant details and grabbed screenshots from two different PCs (both exhibit the same behaviour):

Hope this helps!

[Hung Bui]

Hi Ozzy, 
Thanks for the info. I  have sent this to our team. They will work on it. But I don't think we will change the behavior to response with OUT ACK but to STALL instead. 

[Ozzy]

Hi Hung Bui,

Please keep me posted once this issue is updated! I am currently using SDK v3.2.3 for the nRF54LM20A, and the problem persists. Looking forward to your reply!

[Hung Bui]

Hi Ozzy, 

We haven't got any progress on this issue yet unfortunately. 

But I want to clarify because your distributor also created a ticket ( ) and mentioned that "All subsequent OUT transfers from the host time out, and the device requires a USB re-enumeration or hardware reset to recover." 
My understanding is that what we do is NACK the get descriptor request with length=0 but it still operate with other request after that, is it true ? 

[Ozzy]

Hi Hung Bui,

After the "NACK the GET_DESCRIPTOR request with length=0" action is performed, Endpoint 0 of the nRF54LM20A becomes completely unresponsive to any subsequent requests unless the USB bus re-enumerates the device.

[Hung Bui]

Hi Ozzy,

Could you capture the unresponsive part after the Zero length request being NACKed. From what we can see in the screenshot, it doesn't show that it's non responsive, it simply get NACK. 

Could you show a non-zero length request after the zero length request ? 

[Ozzy]

Hi Hung Bui,

After I issue a zero-length request from the USB host, subsequent non-zero length requests fail to capture any packet at all.

I suspect this could be due to one of two scenarios:

1. The previous SETUP's OUT transaction remains unhandled, preventing the USB host from issuing further SETUP packets to Endpoint 0.
2. After the anomaly, Endpoint 0 is unable to ACK SETUP packets (though I consider this less likely).

[Hung Bui]

Hi Ozzy,

Could you please provide a trace ? Similar to the one above but with non-zero length packet after the zero length one. 

[Ozzy]

Hi Hung Bui,

The screenshot I provided on March 12 already included a non-zero length request sent by the PC after the zero-length request. However, my USB analyzer was unable to capture any data for this non-zero length request! This leads me to believe that the PC may no longer be capable of issuing SETUP requests to our USB device.