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,

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!