Seeing issue while using two CDC com ports

[siddhartha993549]

Hi all,

I am trying to implement two CDC COM ports using TinyUSB. Receiving data from the host to the device works fine, and I can see the data in the buffer. However, when I loop the same data back to the same COM port, after a few iterations one of the COM ports stops working (it can be either one, randomly).

For that port, the API tud_cdc_n_write_available(itf) keeps returning 0. I checked the USB log as well: the host is sending IN tokens, but the device is responding with NAKs only. I am using tud_cdc_n_write() and tud_cdc_n_write_flush() for transmitting data.

Could anyone explain why tud_cdc_n_write_available() keeps returning 0 for one of the ports, and what might cause this behavior?

[HiFiPhile]

Which MCU you are using ? On version 0.20 some code refactor was done for the CDC driver, please try if 0.19 works.

[siddhartha993549]

Thank you for your response. I am currently using TinyUSB version 0.18, and the logic I am trying to implement is shown below.

uint8_t buf[64];

// Get current free space for this CDC interface
uint32_t fifo_space = tud_cdc_n_write_available(CDC_PORT1);

    if (fifo_space > 0)
    {
        uart_buf_count = 0;

        // Copy form 1kb  rx buffer 
        while (uart_buf_count < fifo_space &&
               uart_buf_count < sizeof(uart_buf) &&
               buffer_get(&rx_buffer, &data))
        {
            buf[buf_count++] = data;
        }

        if (uart_buf_count > 0)
        {
            tud_cdc_n_write(CDC_PORT1, buf, buf_count);
            tud_cdc_n_write_flush(CDC_PORT1);
        }
    }

///Repeat the same for 2nd CDC Port

[siddhartha993549]

After some iterations, one CDC port always shows fifo_space = 0, so even when the host sends IN tokens, the device keeps NAKing and cannot transmit.

[HiFiPhile]

Which MCU are you using ?

Please enable logging to get more information, particularly if queued transfers are successfully finished:

Queue EP 81 with 64 bytes ...
USBD Xfer Complete on EP 81 with 64 bytes
Queue EP 02 with 64  bytes ...
USBD Xfer Complete on EP 02 with 64  bytes

[siddhartha993549]

Help Needed on ZLP Handling Issue in MUSB DCD (CDC TX Case)

Hi @HiFiPhile ,

I am working with an MSP432E401Y device and I seem to have narrowed down a CDC transmission issue to Zero Length Packet (ZLP) handling in TinyUSB. I understand the symptom, but I am not sure what the correct fix or expected behavior should be , so I need your guidance.

Root Cause I Observed :

The issue appears to originate from ZLP handling in dcd_musb.c.

If I disable ZLP generation, CDC transmission behaves normally across multiple iterations.
But with ZLP enabled, after a few transfers, one CDC interface endpoint gets stuck , busy and claimed flags remain set forever and no further transfers occur.

Where ZLP is Triggered :

Inside cdc_device.c, in:

bool cdcd_xfer_cb(uint8_t rhport, uint8_t ep_addr, xfer_result_t result, uint32_t xferred_bytes)

When tud_task() invokes this callback:

if (ep_addr == stream_tx->ep_addr) {
tud_cdc_tx_complete_cb(itf);

if (tu_edpt_stream_write_xfer(rhport, stream_tx) == 0) {
    // Send ZLP if required
    tu_edpt_stream_write_zlp_if_needed(rhport, stream_tx, xferred_bytes);
}

}

This eventually causes ZLP submission to the DCD.

Problem Area in dcd_musb.c

Specifically in:

static bool handle_xfer_in(uint8_t rhport, uint_fast8_t ep_addr)

When TinyUSB submits a ZLP, the buffer pointer is NULL and length is zero.

Then in the handler:

rem == 0

execution enters:

if (!rem) {
pipe->buf = NULL;
return true;
}

But since TXRDY is not set, the endpoint never transmits the ZLP, no interrupt fires, and the endpoint remains stuck with busy/claimed flags permanently set.

This results in CDC transfer halt.

My Questions :

1. Is ZLP actually required here?

So far, disabling ZLP handling fixes all issues in my CDC application without adverse effects.
Does CDC TX really need ZLP? If yes, under what conditions?

2. How should ZLP be properly handled?

At DCD (dcd_musb) level, the handler cannot differentiate between:

A genuine ZLP request or normal endpoint buffer becoming empty temporarily

Because both cases look identical (remaining length = 0).

How should this distinction be made so that the DCD sends a real ZLP via TXRDY?

3. UART driven behavior adds confusion

We send data to CDC from UART, which is slower than USB.
Often we send less than 64 bytes because UART buffer availability is limited.

Later, when UART buffer drains, CDC buffer empties temporarily — but we still expect more data shortly.

In this case TinyUSB thinks transfer has ended, so cdcd_xfer_cb() triggers ZLP.

This ZLP was not intended — we just had momentary lack of UART data.

So what is the correct approach to avoid wrong ZLP generation under such conditions?

Any guidance on correct ZLP handling for CDC TX transfer and MUSB controller in the dcd_musb.c would be very helpful.

Thank you!!

[siddhartha993549]

For additional details for dcd_musb.c you can get here : https://linux-sunxi.org/images/7/73/Musbmhdrc.pdf

[HiFiPhile]

Hi @siddhartha993549

Problem Area in dcd_musb.c
Specifically in:
static bool handle_xfer_in(uint8_t rhport, uint_fast8_t ep_addr)
When TinyUSB submits a ZLP, the buffer pointer is NULL and length is zero.
Then in the handler:
rem == 0
execution enters:
if (!rem) {
pipe->buf = NULL;
return true;
}

Thank you for digging into the dcd, there is indeed a ZLP handling issue.

Is ZLP actually required here

ZLP is required by USB 2.0 standard.
Depending on the software implementation, without ZLP the software could be blocking waiting for more bytes to be received.

How should ZLP be properly handled

dcd_musb.c's ZLP handling should be fixed like dcd_stm32_fsdev.c

In this case TinyUSB thinks transfer has ended, so cdcd_xfer_cb() triggers ZLP.

ZLP is only sent when last packet is exactly 64 bytes for FS

UART itself is not a packet level protocol but a stream, additional measure should be used to ensure whole data is received, by the means of timeout (Modbus) or SLIP encoding

[HiFiPhile]

I came up with a quick fix without having MSP432 for testing:

diff --git a/src/portable/mentor/musb/dcd_musb.c b/src/portable/mentor/musb/dcd_musb.c
index ad20d64bd..cdd4cf8fc 100644
--- a/src/portable/mentor/musb/dcd_musb.c
+++ b/src/portable/mentor/musb/dcd_musb.c
@@ -256,14 +256,14 @@ static void process_setup_packet(uint8_t rhport) {
   }
 }
 
-static bool handle_xfer_in(uint8_t rhport, uint_fast8_t ep_addr)
+static bool handle_xfer_in(uint8_t rhport, uint_fast8_t ep_addr, bool zlp)
 {
   unsigned epnum = tu_edpt_number(ep_addr);
   unsigned epnum_minus1 = epnum - 1;
   pipe_state_t  *pipe = &_dcd.pipe[tu_edpt_dir(ep_addr)][epnum_minus1];
   const unsigned rem  = pipe->remaining;

-  if (!rem) {
+  if (!rem && !zlp) {
     pipe->buf = NULL;
     return true;
   }
@@ -335,7 +335,7 @@ static bool edpt_n_xfer(uint8_t rhport, uint8_t ep_addr, uint8_t *buffer, uint16
   pipe->remaining    = total_bytes;

   if (dir_in) {
-    handle_xfer_in(rhport, ep_addr);
+    handle_xfer_in(rhport, ep_addr, pipe->length == 0);
   } else {
     musb_regs_t* musb_regs = MUSB_REGS(rhport);
     musb_ep_csr_t* ep_csr = get_ep_csr(musb_regs, epnum);
@@ -512,7 +512,7 @@ static void process_edpt_n(uint8_t rhport, uint_fast8_t ep_addr)
       ep_csr->tx_csrl &= ~(MUSB_TXCSRL1_STALLED | MUSB_TXCSRL1_UNDRN);
       return;
     }
-    completed = handle_xfer_in(rhport, ep_addr);
+    completed = handle_xfer_in(rhport, ep_addr, false);
   } else {
     // TU_LOG1(" RX CSRL%d = %x\r\n", epn, ep_csr->rx_csrl);
     if (ep_csr->rx_csrl & MUSB_RXCSRL1_STALLED) {

[siddhartha993549]

Hi @HiFiPhile ,

Thank you for the help and the quick fix suggestions 😃!!

I’ll try it on the MSP432 MCU and let you know how it goes.