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!

[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.

[Hung Bui]

Hi Ozzy,

So it's more likely that it's the host got non-response after the NACK from the nRF54 ? And not that the nRF54 hang ?  

[Ozzy]

Hi,Hung Bui,

 After this condition occurs, Endpoint 1 can still respond to host requests normally (our mouse data continues to be uploaded via Endpoint 1 without issues). This suggests that only Endpoint 0 is affected by the anomaly.

[Hung Bui]

Hi Ozzy, 
Our team is still focusing on responding with STALL instead of NACK. 

Since it's the host that send the OUT token when it's supposed to send IN token, and after receiving out NACK it's the host that become unresponsive on Endpoint 0, not much we can do except for sending STALL instead of NACK.

We will keep you updated when we implement the fix. 

[Ozzy]

Hi!
Any updates on this recently? Our LM20A is about to enter mass production. I tested the latest SDK v3.3.0 and the issue is still there. Looking forward to your reply!