USB NYET response despite of free buffer (LPC55S69 USB1 HS Controller)

[pettel]

I'm using EP2 OUT with double buffering.

• Buf0 and Buf1 have 2048 bytes each
• EP2 OUT is a bulk endpoint with a maximum packet size of 512 bytes

Both endpoints (EP2_OUT_BUF0, EP2_OUT_BUF1) are initialized with 2048 N-bytes and the endpoints are set to active.

Expectation: without further interaction 4096 bytes should be received, without a NYET response.

Observed behaviour: after Buf0 is full a NYET response is transmitted instead of an ACK response, despite Buf1 beeing completely empty and active.

This behaviour is especially detrimental to performance if you work with 512 byte buffers for Buf0 and Buf1, because in this case a NYET response is transmitted after every OUT transmission from the host, which requires an unnecessary USB-Ping and reduces throughput.

Is there a workaround or is this a hardware bug?

  

[EdwinHz]

Hi @pettel,

This is by design of the USB stack implementation of the SDK. As you can see on a comment on "PERI_USBHSD.h": 

DATA_PENDING - As long as this bit is set to one and LPM supported bit is set to one, HW will
* return a NYET handshake on every LPM token it receives. If LPM supported bit is set to one and
* this bit is zero, HW will return an ACK handshake on every LPM token it receives. If SW has
* still data pending and LPM is supported, it must set this bit to 1.

[pettel]

Hi @EdwinHz ,

this topic is not about LPM tokens. It's about sending user data from the USB host to EP2 of the LPC55S69. Link Power Management and the associated transactions are a completely separate topic.

[EdwinHz]

Hi @pettel,

At high speed, bulk OUT endpoints use the PING/NYET mechanism in the following manner:

If the device ACKs, the host may immediately send another payload. However, if the device NYETs, the host must PING before sending the next data packet. With two endpoint banks, hardware is supposed to ACK as long as at least one bank remains available and primed.

On LPC55S6x USB1 HS device (IP3511HS), the “double buffer” is software‑managed. The SDK and reference designs keep track of which bank is “in use” and which is ready using software toggles. The next bank is not automatically considered “ready for the next payload” just because it’s empty, you must prime/validate it, and the hardware’s EPINUSE/EPTOGGLE needs to reflect that before the host’s next transaction. If the bank isn’t armed in time, the device will finish the current packet and return NYET.

BR,
Edwin.

[pettel]

Hi Edwin,

thank you for the prompt response!

I am fully aware of the NYET/PING mechanism and I know, that if the next buffer in not initialized properly, the device will respond to the host with a NYET.

To be more precise in the original post, I should have written "both endpoint out buffers...".

I would like to know, if you would agree, that if you have both buffers (2048 bytes for each buffer, 512 bytes per BULK packet) completely activated/primed for the transfer, before the  BULK OUT transfer starts, then at least 8 BULK OUT packets should be able to be sent from the host to the device without receiving a NYET response.

But in reality in this scenario, I get a NYET response already after 4 BULK OUT packets, even if both buffers are completely primed for the transfer. The initialization code for both buffers is triggered by the control transfer that is visible in the screenshot from the USB analyzer in the original post.

Do you have a test firmware for USB HS performance, that does nothing but reinitializing a buffer after the transfer in this buffer is completed?

I did not use any part of CMSIS or the SDK libraries. Instead I wrote my own HAL and USB stack from scratch in Zig.

The code, which is triggered by the control transfer before the EP2 OUT transfer is started, looks like this:

```zig
...
ep2.out.initEpBuffer0();
ep2.out.initEpBuffer1();
...
```

EP2 OUT Module code for initializing the buffers:

```zig
pub fn initEpBuffer0() void {
EndPoint.ep_cmd_stat_list.ep2_out_buf_0.buffer_address_offset = EndPoint.ep_cmd_stat_address_offset_ep2_out_buf0;
EndPoint.ep_cmd_stat_list.ep2_out_buf_0.buffer_nbytes = config.LinkerConfig.usb_hs_ep2_out_buffer_size;
EndPoint.ep_cmd_stat_list.ep2_out_buf_0.active = .buffer_active;
}

pub fn initEpBuffer1() void {
EndPoint.ep_cmd_stat_list.ep2_out_buf_1.buffer_address_offset = EndPoint.ep_cmd_stat_address_offset_ep2_out_buf1;
EndPoint.ep_cmd_stat_list.ep2_out_buf_1.buffer_nbytes = config.LinkerConfig.usb_hs_ep2_out_buffer_size;
EndPoint.ep_cmd_stat_list.ep2_out_buf_1.active = .buffer_active;
}
```

Looking forward to your feedback!