adding tinyUSB to working HTTPS server application for logging through USB leads to undefined program behavior (IDFGH-8227)

ralphde commented 2 years ago

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v4.4.1

Operating System used.

Windows

How did you build your project?

Eclipse IDE

If you are using Windows, please specify command line type.

No response

What is the expected behavior?

one remark, that I can not submit an issue for older versions means hat I always have to upgrade before I can submit an issue report? I expect that adding tinyUSB for logging over USB following the documentation does not change anything in program behavior then just logging over USB even in 4.4.1

What is the actual behavior?

It is a very strange issue I am facing and I don't know really how to explain it because the issue has not a constant behavior. After days of reviewing my application code looking at all memory allocation on stack and moving any buffer possible to heap to spare stack space the problem remains. After using tinyUSB and redirecting the std output using ACM the program is running but its behavior is completely different and not at all what the code should do. So the only conclusion can be that something ruins the stack of the HTTPS server task. The most obvious issue is that tinyUSB repeats at full speed the last LOGx message sent to logging library indefinitely sent from the HTTPS server task

I have selected to use its own task for the tinyUSB library

Nevertheless it seems to me that the logging library in junction with the tinyUSB library go out of bound on the calling stack.

How can I debug this ? any tool for this sort of problem provided in the IDF ?

Here the code how I init the acm:

`

tinyusb_config_t tusb_cfg = { 0 }; // the configuration uses default values
ESP_ERROR_CHECK(tinyusb_driver_install(&tusb_cfg));

tinyusb_config_cdcacm_t amc_cfg = { 0 }; // the configuration uses default values
ESP_ERROR_CHECK(tusb_cdc_acm_init(&amc_cfg));

esp_tusb_init_console(TINYUSB_CDC_ACM_0); // log to usb

// give time for a Windows PC to setup USB device
vTaskDelay(10000 / portTICK_PERIOD_MS);

ESP_LOGI(TAG, "log -> USB");
//printf( "File:%s Line:%i says:%s %s\n" , __FILE__, __LINE__, TAG, "log -> USB");

`

Steps to reproduce.

take a HTTPS server application, serving pages from SD card using and processing request parameters and at the final stage add logging over tinyUSB. On one of the ESP_LOGx calls, tinyUSB library repeats the last message infinitely until another ESP_LOGx call is done, if the program did not stall before.

Using debugging over JTAG is impossible because the code does not run at all in debug mode when using tinyUSB.

I repeat here, that all works fine if tinyUSB is not used for logging incl. jtag debugging.

Build or installation Logs.

No response

More Information.

No response

ralphde commented 1 year ago

@tore-espressif this issue is really a pain in the a.... what can I do that somebody looks into this?

tore-espressif commented 1 year ago

Hi @ralphde , I'm sorry for the delayed response, it must have slipped my attention.

The symptoms sound interesting. I will have a look. In the meantime, could you please try the following:

Are you running on ESP32-S3? If yes, could you try running the same code on EPS32-S2? (to rule out dual CPU issues)
In menuconfig ->FreeRTOS->kernel setup CHECK_FOR_STACK_OVERFLOW
In menuconfig -> Heap memory debugging -> Heap corruption detection -> Comprehensive
Increase the RX/TX FIFOs to 2048

ralphde commented 1 year ago

Hi @tore-espressif nice following this up. I am using ESP32-S2

I have experienced stack overflows and increased accordingly. But this occurred without tinyUSB enabled.

I experimented with stack size to see if this affects tinyUSB, but could not find any relation to this issue

for point 4 I am not clear which and where else FIFOS size to increase. I played with the tinyUSB tx/rx buffer size. No influence to this issue.

this error can occur with any log message at any time. it is not a specific message and no relation to size of the message.

It looks to me that a flag 'buffer send' is not set or what ever mechanism is used to indicate that the message was send. I want to mention again that the next message sent recovers the issue. but until then the last message is send full speed infinitive.

For some other reasons I had to revert back to 4.4.1. However the issue was the same in 4.4.2

espressif / esp-idf