USBD CDC ACM 64 Byte Limit

[Mark J]

Hi,

I have a simple question ... I think.

I have been limiting my USBD reads/writes to 64 bytes as NRFX_USBD_EPSIZE and NRF_DRV_USBD_EPSIZE are set to 64 bytes. I have read that the CDC ACM standard supports larger packet sizes (I recall up to 1024). 

I would like to to support 256 byte buffer read and writes. Can I just ignore the defines and write more data (ie. up to 256 bytes)? 

Do I need to change any defines to support larger read/writes?

If it matters, I am using nRF52840 and SDK 15.3 with S140.

Thanks in advance.

Mark J

[Turbo J]

Mark J said:

I have read that the CDC ACM standard supports larger packet sizes (I recall up to 1024). 

Not for USB 2.0 Full speed connections. USB 2.0 full speed only supports 64 data bytes / packet for bulk endpoints, and that is also the easydma limit.

[Mark J]

Thanks Turbo J.

I can see the distinction now.

If I write more than 64 bytes (for example), does the USBD driver support breakup into 64 byte packets - or do I need to breakup larger messages myself? There are no clearly defined message limits within Nordic docs.

I can test, but the answer to this question should be referenceable.

Thanks,

Mark J

[Mark J]

I have empirically tested and determined that I can send more than 64 bytes. When receiving on a Linux host, I am getting up to 128 byte messages. So, if I send 160 bytes over USBD, I receive a msg with 128 bytes followed by another with 32 bytes.

I suspect that the 128 byte limit may be a Linux CDC driver threshold for reads and may not have anything to do with the Nordic USBD driver.

Mark J

[Turbo J]

Careful: USB on the host works a lot different than on the NRF µC.

The host will assemble a large transaction from smaller 64 byte packets (as mandated by USB spec) - this works for both IN and OUT bulk endpoints.

The NRF USB peripherial has a hard 64 byte limit for bulk ep EasyDMA. The CDC API can work around this limit IIRC by splitting larger transactions into 64 byte packets.

[Mark J]

Yes, understood. I think the practical point is that you can send more 64 bytes through the Nordic USBD api write call - you do not have to explicitly break msgs into 64 byte (or less) parts.

[Mark J]

Well - its been a beat. Our host device (our IoT Gateway) evolved and now supports a newer version of Debian (now 11, was 10). The CDC ACM driver in our host is not handling any writes larger than 64 bytes. So - always use less than 64 bytes to be safe and do not rely on the driver handling multiple 64 byte messages.

Actual comms behavior was strange. When sending 256 byte msgs, most would get through - except the last msg.

Msging appears ok now that I have reduce app msgs to 64 bytes or less.

[Turbo J]

Smells like you missed the chapter in the USB spec how usb bulk transactions work.

Integer multiples of MaxPacketSize (64) need a zero packet in order to properly signal the transaction end back to the host stack.