ESP32-S2 USB-ACM target device [NOT UART]: hang on receive

[hpax]

Board

ESP32-S2-WROVER-I

Device Description

WROVER module on custom board (see below).

Hardware Configuration

Serial port (UART 0):
GPIO 0 - DTR
GPIO 43, 44 - RX/TX

LEDs:
GPIO 2, 3, 4

USB-C power control FETs: (configured as power sink)
#define PIN_USB_PWR_EN 7
#define PIN_USB_PWR_SINK 8

SPI link to FPGA: (using SPI2)
#define PIN_FPGA_CS2 1 /* Unused */
#define PIN_FPGA_INT 9
#define PIN_FPGA_CS 10
#define PIN_FPGA_IO0 11
#define PIN_FPGA_CLK 12
#define PIN_FPGA_IO1 13

JTAG link to FPGA:
#define PIN_FPGA_TDI 16
#define PIN_FPGA_TDO 17
#define PIN_FPGA_TMS 14
#define PIN_FPGA_TCK 18

I2C device (RTC); shared with FPGA (not never used by ESP32-S2):
#define PIN_I2C_SDA 5
#define PIN_I2C_SCL 6
#define PIN_RTC_32KHZ 15

External header:
GPIO 0, 21, 33-39 (includes ESP32-S2 JTAG and UART)

Schematic:
https://max80.abc80.org/docs/max80v2.sch.pdf

Version

v2.0.14

IDE Name

arduino-cli

Operating System

Linux

Flash frequency

Default (80 MHz I believe?)

PSRAM enabled

yes

Upload speed

921600

Description

Note: Serial = USB-ACM; Serial1 = UART

The ESP32-S2 ACM port using Serial.read() for reviewing data hangs fairly randomly; sometimes it is possible to download over a megabyte, but more frequently it hangs after about 400K, at least in my application.

Once it is hung, it can neither transmit nor receive.

This happened before ACM was broken in 2.0.10 (or thereabouts) and is happening again with 2.0.14.

Sketch

See https://git.zytor.com/abc80/max80/fw.git/tree/esp32/max80/tty.cpp

Debug Message

None

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.

[TD-er]

Since you're interacting with something on a SPI bus, the first idea popping in my head is that you may need to put some code in IRAM or data explicitly in internal memory and make sure it doesn't need to read from flash nor PSRAM while handling your callback functions.

Also your TTY::_onrx() function is way too long and does send data to some port().
Just copy incoming data to some buffer and set a flag to make sure it has to be processed.
Then process the data from your usb_task_handler function. (or some other task function)

The TTY::_onrx() function is called as a callback from an event. These calls should be as short as possible and also not try to interact with other hardware which may take some time. (also memory allocation takes time, which is done in the MSG function calls)

And I saw at least one possible out of bounds check done wrong:

	    if (rx.rlen < sizeof fwupload_start &&
		byte == fwupload_start[rx.rlen]) {
		if (!fwupload_start[++rx.rlen]) {

I did not know you could use sizeof without (), so at least to me it is quite confusing to read. Not sure about any ambiguity in your code for the compiler.
For example this one: if (len > sizeof buf - 2) {

[hpax]

sizeof has higher precedence than subtraction. Using sizeof without parentheses is valid if the argument is an object rather than a type; I tend to use the "naked" sizeof if I want to make sure the argument is an object.

TTY::_onrx is not called in a callback context in the case of USB-CDC:

case ARDUINO_USB_CDC_RX_EVENT:
    xTaskNotifyIndexed(usb_tty_task, USB_NOTIFY_INDEX, 1, eSetBits);
    break;

[...]

void TTY::usb_task_handler(void *pvt)
{
(void)pvt;

while (1) {
uint32_t notify_value;

xTaskNotifyWaitIndexed(USB_NOTIFY_INDEX, 0, 1,
		       &notify_value, portMAX_DELAY);
usb_tty->_onrx();
}

}

usb_task_handler is a separate thread:

if (xTaskCreate(usb_task_handler, "usbttyd",
	    USB_TASK_STACK, usb_tty,
	    USB_TASK_PRIORITY, &usb_tty_task) == pdPASS) {
Serial.onEvent(usb_onevent);
xTaskNotifyIndexed(usb_tty_task, USB_NOTIFY_INDEX, 1, eSetBits);
}

So that isn't the problem. I did try to increase the USB Rx buffer size, thinking that my problem might be caused by an input buffer overrun, but I don't see any evidence of that happening (and increasing the Rx buffer size seemed to have absolutely no effect.)

I do call it in the callback path in the case of UART, but the code works just fine in the UART case.

The problematic peripheral is not UART, it is USB-ACM.

[Parsaabasi]

Hello,

Due to the overwhelming volume of issues currently being addressed, we have decided to close the previously received tickets. If you still require assistance or if the issue persists, please don't hesitate to reopen the ticket.

Thanks.