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

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

Children
Related