Frequent -16 Error When Using USB CDC with UART Async TX at 102 kB/s

[Ben_M]

Hi all,

I’m developing firmware using USB CDC with UART async API to transmit data at about 102 kB/s. However, during uart_tx() calls, I often get a -16 error (EBUSY). Sometimes the transmission succeeds after several retries.

Here’s my setup and logic:

1. Bluetooth (NUS service) receives about 204 bytes every 2 ms.

2. After receiving data, I push it into a message queue (k_msgq) for the UART TX thread.

3. The UART TX thread retrieves data from the queue and immediately calls uart_tx().

4. After sending, the thread waits about 1 µs before checking the queue again.

Issue:

• uart_tx() frequently returns -16 (EBUSY).

• Sometimes it takes several retries before the data can be sent successfully.

Question:

• What is the most likely cause of the frequent -16 errors in this async setup?

• Is there a recommended way to manage continuous data transmission via USB CDC (UART async) to avoid TX busy states?

Thank you for your support!

Best Regards!

Ben

[Turbo J]

That is very close to the USB transfer limit that I get here when directly attached to a PC host.

I am getting significantly more throughput with an USB hub in between the NRF chip and the PC (~300KB/sec instead of ~100KB/sec). Reason is the way USB transfers are scheduled by the host OS - you get better timing (latency) via the USB hubs USB 2.0 high speed connection to the host even though the actual transfers are still full speed on the device side.

[Simonr]

Hi Ben

1. Just in general, if the uart_tx() function returns an EBUSY that suggests that the UART driver is already transferring something, so I assume the previous transfer/reception isn't completed when you call the uart_tx() function here. What should be added is some sort of check to make sure the UART is finished with one task before you start the next. Does lowering the throughput help with mitigating this issue for example? 

2. Generally, a check that the UART is done transferring before a new task is called is the recommended way to avoid busy states from the UART.

Best regards,

Simon

[Ben_M]

Hi Turbo,

Thanks for your help!

I found the max speed limit is 215kB/s for Windows from the case. Did I miss any information? And I will test by USB hub.

Thank you again for your help!

Best Regards!

Ben

[Ben_M]

Hi Simonr,

Is there any other way to avoid err except lowering rate? eg. increasing the buffer length before tx? This raises another question: is this rate the MAX limit, or caused by kernel scheduling?

Best Regards!

Ben

[Simonr]

Hi Ben

The buffer length doesn't seem to be the issue here, since you are calling the uart_tx() function before the last one was completed. What baud rate have you currently set? The supported UART baud rates from a HW perspective are stated in the datasheet: https://docs.nordicsemi.com/bundle/ps_nrf52840/page/uart.html#ariaid-title34 

115200 is the default, but can be increased for as high as the driver supports.

Best regards,

Simon