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

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

Parents
  • 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.

Reply
  • 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.

Children
Related