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.