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

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

Hung Bui — Mon, 23 Mar 2026 10:21:24 GMT

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.

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

Ozzy — Tue, 17 Mar 2026 09:38:26 GMT

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.

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

Hung Bui — Tue, 17 Mar 2026 08:50:21 GMT

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 ?

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

Ozzy — Tue, 17 Mar 2026 01:19:17 GMT

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.

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

Hung Bui — Mon, 16 Mar 2026 11:58:10 GMT

Hi Ozzy,

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

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

Ozzy — Sat, 14 Mar 2026 03:02:06 GMT

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

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

Hung Bui — Fri, 13 Mar 2026 12:38:58 GMT

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 ?

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

Ozzy — Thu, 12 Mar 2026 09:51:36 GMT

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.

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

Hung Bui — Thu, 12 Mar 2026 09:18:57 GMT

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 ?

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

Ozzy — Wed, 04 Mar 2026 03:53:16 GMT

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!

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

Hung Bui — Tue, 10 Feb 2026 08:34:19 GMT

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.

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

Ozzy — Sat, 31 Jan 2026 02:31:59 GMT

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!

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

Hung Bui — Fri, 30 Jan 2026 12:11:21 GMT

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.

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

Ozzy — Fri, 30 Jan 2026 06:30:05 GMT

Hi Hung Bui,

Thank you for getting back to me. Let me add a few clarifications based on your questions:

1. I’m not sure what you mean by “actual host controller.”
The machines I have tested are ordinary Windows 10 and Windows 11 PCs; the nRF54LM20A is enumerated as a USB-HID mouse on those systems.

2. I use a tool called **Bus Hound** to inject the exact request. The procedure is:
2.1 Double-click the target device in the device list.
2.2 Select “USB” as the protocol.
2.3 Fill in the eight bytes of the SETUP packet (e.g. 80 06 00 06 00 00 0A 00).
2.4 Press “Run”; the PC immediately transmits that request downstream.
Screenshot below for reference:

3. Your developers are absolutely right: as a rigorous vendor, Nordic should follow the USB spec to the letter.
My only goal was to surface this real-world behaviour—seen on many commodity PCs—to let you decide whether a workaround is warranted.

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

Hung Bui — Thu, 29 Jan 2026 12:44:00 GMT

Hi Ozzy,
Thanks for the confirmation.
Our developer think that we need to follow the spec. In this case the device should respond with STALL packet instead of NAK packet after it receives unexpected OUT packet + DATAx packet.

We want to know which host you used. You mentioned Windows but we want to know the actual host controller. Also please let us know which software you used to trigger GetDescriptor() with wLength=0

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

Ozzy — Thu, 29 Jan 2026 03:05:56 GMT

Hi Hung Bui,

Thank you for your prompt response.

I have just revisited the USB 2.0 specification, and you are absolutely right: the spec clearly states that for a zero-length Control Read transfer the Data stage shall be omitted and the host must issue an IN token in the Status stage.
However, in roughly 95 % of the PCs we have tested, the sequence is different:

1. The host(windows PC) correctly skips the Data stage;
2. Nevertheless, in the Status stage it still sends an **OUT token** instead of the expected IN token.

The capture below illustrates this behaviour: although the request is a zero-length Control Read, the Windows driver simply bypasses the IN Data stage and immediately proceeds to what it treats as the Status stage—expecting the device to ACK the OUT packet.

In other words, the host does **not** follow the “no-data control” flow you mentioned; it still performs an OUT handshake for status.

Because of this widespread host-side deviation, my previous implementations (on other MCUs) always arm **both** IN and OUT endpoints with ACK whenever a zero-length Control Read is detected. This guarantees compatibility with hosts that violate the strict spec sequence.

Best regards,
Ozzy

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

Hung Bui — Wed, 28 Jan 2026 12:21:27 GMT

Hi Ozzy,

I want to have some clarification to align with you about the correct response.

According to spec and our understanding:

9.3.5 wLength

This field specifies the length of the data transferred during the second phase of the control transfer. The
direction of data transfer (host-to-device or device-to-host) is indicated by the Direction bit of the
bmRequestType field. If this field is zero, there is no data transfer phase.

9.3.1 bmRequestType

[...] The state of the Direction bit is ignored if the wLength field is zero, signifying there is no Data stage.

8.5.3 Control Transfers

[...] If the control sequence has no Data stage, then it consists of a Setup stage followed by a Status stage consisting of an IN transaction.

So my understanding is that host is expected to send IN token after the GET_DESCRIPTOR with wLength=0.

Could you confirm ?

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

Hung Bui — Tue, 27 Jan 2026 13:48:22 GMT

Hi Ozzy,
I have forwarded your question internally. Will keep you updated.