USBCDC::flush is blocking

[tablatronix]

Board

ESP32 S3

Device Description

S3 mini devkit

Hardware Configuration

Nothing special S3 mini

build_flags = -DDEBUG_ESP_WIFI -DESP32 -DCORE_DEBUG_LEVEL=5 -DWM_DEBUG_LEVEL=3 -DARDUINO_USB_MODE=1 -DARDUINO_USB_CDC_ON_BOOT=1 -DARDUINO_USB_DFU_ON_BOOT=1

Version

v2.0.5

IDE Name

pio

Operating System

osx:latest

Flash frequency

40

PSRAM enabled

no

Upload speed

921600

Description

USBCDC flush() will block until you connect to it and it can flush.. seems odd,

!tud_cdc_n_connected is reporting wrong?

void USBCDC::flush(void)
{
    if(itf >= MAX_USB_CDC_DEVICES || tx_lock == NULL || !tud_cdc_n_connected(itf)){
        return;
    }
    if(xSemaphoreTake(tx_lock, tx_timeout_ms / portTICK_PERIOD_MS) != pdPASS){
        return;
    }
    tud_cdc_n_write_flush(itf);
    xSemaphoreGive(tx_lock);
}

Sketch

void setup(){
Serial.begin(115200);
Serial.println("Booting....");
delay(200);
Serial.flush();
// we never get here
}

Debug Message

I will have to attach a physical uart and check if there is any notice

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[SuGlider]

@tablatronix
The issue is -DARDUINO_USB_MODE=1 that is used with Hardware USB CDC. It uses HWCDC.h/.cpp

TinyUSB requires -DARDUINO_USB_MODE=0. It uses USBCDC.h/.cpp

ESP32-S3 can only use one or the other. Not both at the same time.

[tablatronix]

Ok so I posted the wrong method, I will take a look at HWCDC.*,
But I don't see how that affect the issue, It is still an unexpected issue/bug

[tablatronix]

I am working around this now by checking initial_empty not sure its purpose, but it seems to be useful enough for bus state so flush doesn't sit there waiting for USB_SERIAL_JTAG_INTR_SERIAL_IN_EMPTYor whatever indefinitely

I tried to use tx_timeout_ms to break xSemaphoreTake, but coudln't get it to fail.

void HWCDC::flush(void)
{
    if(tx_ring_buf == NULL || tx_lock == NULL || !initial_empty){
        return;
    }
    if(xSemaphoreTake(tx_lock, tx_timeout_ms / portTICK_PERIOD_MS) != pdPASS){
        return;
    }

[tablatronix]

There also is something wrong with HWCDC ISRs and wifi..

To get wifi working with HWCDC, I have to setRxBufferSize + to get wifi to work ( blocking ISR??) . or setTxTimeoutMs low, probably very similar issue but in write blocking

And there is some delay proportional to the size of the buffer, so something is waiting until it's full ?

[tablatronix]

yup same issue, fixed the same way , well kludged. But yeah if we can make HWCDC not get stuck blocking/waiting when no client is present or when no async event will ever be reached.

I see that write - xRingbufferSend has non blocking, but I have not looked into what going on there or if its using it

[SuGlider]

I have tested it and I can't reproduce the issue.

When you run the ESP32S3, the USB cable is unplugged?
Please provide more details on how to reproduce the issues you are experimenting.

[tablatronix]

Usb is plugged but no serial connected. Could this be an osx issue with dtr? Behavior differs with and without a serial terminal on the socket

[SuGlider]

I have Win11 here. I don't know if this is an osx issue only.

But, yes, when a Serial Terminal is initiated, there is a signal to USBCDC that tells to Arduino that the connection has been started.
Before opening the Terminal Window using /dev/ttyUSBxx, Arduino CDC will not work (read/write), therefore, USBCDC::flush() may block, once it is never able to send the data through the USB end point, and then never return.

https://github.com/espressif/arduino-esp32/blob/master/cores/esp32/USBCDC.cpp#L238-L240

The sketch can test if it has been connected already by using

  if(Serial) {
    log_i("USB Serial Terminal has started and connected to CDC.");
  } else {
    log_i("USB Serial Terminal in not connected to CDC.");
  }

Given that flush() should only return if data is sent, I think that blocking when there is no CDC connection may be the right behavior.

[imwhocodes]

Hi @tablatronix

I'm having the same problem and I proposed a PR #7721

If you can (super easy with PlatformIO) you can test using this branch: https://github.com/imwhocodes/arduino-esp32/tree/usb-unconnected-stall-fix

platform_packages = 
	platformio/framework-arduinoespressif32 @ https://github.com/imwhocodes/arduino-esp32#usb-unconnected-stall-fix

@SuGlider

Given that flush() should only return if data is sent, I think that blocking when there is no CDC connection may be the right behavior.

Yes this is True but in the UART case there is no concept of "connection", Stream::flush() on UART will take maximum (pending_bytes * 10) / baudrate time (10 is for converting bytes to bauds) and never stall indefinitely

I would argue that if no usb is connected all write should be NO-OP and not even try to actually write on the medium
And there is still operator HWCDC::bool() const if you want to wait for the usb to be connected