Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESP32 S3 serial and USB HID stall when DTR is activated a second time #9582

Closed
1 task done
ChrGri opened this issue May 2, 2024 · 28 comments
Closed
1 task done

ESP32 S3 serial and USB HID stall when DTR is activated a second time #9582

ChrGri opened this issue May 2, 2024 · 28 comments
Assignees
Labels
Status: Needs investigation We need to do some research before taking next steps on this issue Type: Question Only question

Comments

@ChrGri
Copy link

ChrGri commented May 2, 2024

Board

ESP32 S3 dev

ESP32 S3 DevKitC 1 N16R8 ESP32 S3 WROOM1 N16R8 Entwicklungsboard WiFi Bluetooth 5.0 Mesh Entwicklungsboard https://amzn.eu/d/iAX62Sv

Device Description

esp32-s3-devkitc-1

The platformIO file can be found in the code section.

Hardware Configuration

USBOTG connection to PC

Version

latest master (checkout manually)

IDE Name

PlatformIO

Operating System

Win 11

Flash frequency

PSRAM enabled

no

Upload speed

Description

ESP32 S3 runs simple program that should provided USB HID gamepad and serial messages via USB OTG port. Im using the Windows inbuilt USB gamecontroller program to monitor the gamepad data and this serial monitor app to monitor the serial messages. The serial monitor app allows to set the DTR/RTS states manually, by pressing the red marked software buttons

image

The first activation of DTR enables the serial output as expected. When DTR is disabled, USB HID output continiues, which is also expected. But, when DTR is activated a second time, USB HID and serial output stall, which is not as expected.

DtrProblem.mp4

Apart from that, when serial and USB HID output are activated, both will stall after a while, see.

Sketch

Can be found here:
https://github.com/ChrGri/DIY-Sim-Racing-FFB-Pedal/tree/develop/Validation/Joystick_Serial_test

Debug Message

-

Other Steps to Reproduce

  1. Flash firmware
  2. Open serial monitor app
  3. Connect to COM port
  4. Enable DTR
  5. Check USB HID and serial output
  6. Deactivate DTR
  7. USB HID output still updating
  8. Activate DTR
  9. USB HID and serial output stall

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

  • I confirm I have checked existing issues, online documentation and Troubleshooting guide.
@ChrGri ChrGri added the Status: Awaiting triage Issue is waiting for triage label May 2, 2024
@SuGlider
Copy link
Collaborator

SuGlider commented May 6, 2024

Is this about USB Serial Device (CDC-ACM) signals?

@SuGlider
Copy link
Collaborator

SuGlider commented May 6, 2024

@ChrGri - please keep in mind that DTR and RTS signals of the USB CDC port actually control "reset" and "boot mode" signals of the ESP32-S3.

@SuGlider
Copy link
Collaborator

SuGlider commented May 6, 2024

It may be putting the S3 into download mode... "freezing/halting" the S3 firmware execution...

@SuGlider
Copy link
Collaborator

SuGlider commented May 6, 2024

@ChrGri - Please read this: #6762 (comment)

image

@SuGlider
Copy link
Collaborator

SuGlider commented May 6, 2024

This behaviour can be disabled permanently by burning the correct eFuse.

@SuGlider SuGlider added Type: Question Only question Status: Solved and removed Status: Awaiting triage Issue is waiting for triage labels May 6, 2024
@ChrGri
Copy link
Author

ChrGri commented May 6, 2024

@SuGlider Thank you very much. I understood, that to enter the download mode on a regular ESP, one has to execute a specific DTR/RTS sequence, as shown below
image.

From the documentation you referenced, I understood that only the download mode flag is toggled, but the chip is never asked to reset:
image

I think setting Serial.enableReboot(false) has improved the behaviour and the USB HID output is continuous independent of the DTR state. However, simultaneous USB HID and serial output while RTS/DTR sates beeing const. are still buggy and both stall after some time. Single output of serial data or single output of USB HID data works fine though.

BR
Chris

@SuGlider
Copy link
Collaborator

SuGlider commented May 6, 2024

However, simultaneous USB HID and serial output while RTS/DTR sates beeing const. are still buggy and both stall after some time. Single output of serial data or single output of USB HID data works fine though.

I see that you are using PlatformIO. What is the Arduino Core version used with it?
If possible, could you test it with Arduino IDE using Arduino Core 3.0.0-RC1?

@ChrGri
Copy link
Author

ChrGri commented May 6, 2024

However, simultaneous USB HID and serial output while RTS/DTR sates beeing const. are still buggy and both stall after some time. Single output of serial data or single output of USB HID data works fine though.

I see that you are using PlatformIO. What is the Arduino Core version used with it? If possible, could you test it with Arduino IDE using Arduino Core 3.0.0-RC1?

I've changed the platformIO as shown below. No difference.
image

You can find the sample code here. I've played around with Serial.setTxTimeoutMs(0); and Serial.flush(); without success. The observation is always, as soon as USB HID and serial output are activated together, the output will stall at some point.

BR
Chris

@ChrGri
Copy link
Author

ChrGri commented May 6, 2024

One thing which helped a lot, was adding a delay between the serial write and USB HID output command, as such
image.

Wit that delay, the serial and USB HID output don't seem to stall immediately. Reducing the delays to 1ms will make the output stall eventually. I'm a bit confused, that replacing the delays with Serial.flush() doesn't seem to have the same effect.

BR
Chris

@SuGlider
Copy link
Collaborator

SuGlider commented May 6, 2024

I understand that your project uses USB OTG and TinyUSB for both, HID and CDC.
The delay seems to give TinyUSB some room to run different tasks from those 2 endpoints and/or their tasks...

It may be necessary to run a deep investigation of this issue.

@ChrGri
Copy link
Author

ChrGri commented May 6, 2024

I understand that your project uses USB OTG and TinyUSB for both, HID and CDC. The delay seems to give TinyUSB some room to run different tasks from those 2 endpoints and/or their tasks...

It may be necessary to run a deep investigation of this issue.

Yes, CDC and HID. Do you have an idea, why Serial.flush() apparently doesn't give that room too?

Is there something I can to help to find a proper fix?

Edit:
Btw. setting the first delay to 500ms and disabling the second delay results in a stall again. Seems to be purely related to the immediate HID output call after the serial write call.

BR
Chris

@SuGlider
Copy link
Collaborator

SuGlider commented May 6, 2024

I'd need to analyse it better and try to understand why it could fail.

Regarding Serial. Flush(), it actually just waits until all the data is sent to the USB Host.
By other hand, delay(time_ms) releases the FreeRTOS Scheduler to run another task while waiting for that time to pass.

Arduino has a 1 ms time slice defined for FreeRTOS.
delay(5); means waiting for 5 time slices while other tasks could be executed - maybe something related to HID...
This is the "room" that I've mentioned about.

It is necessary to see the whole picture and try to understand the sequence of actions and possible reasons for the issue.

@SuGlider SuGlider added Status: Needs investigation We need to do some research before taking next steps on this issue and removed Status: Solved labels May 6, 2024
@ChrGri
Copy link
Author

ChrGri commented Jun 5, 2024

Just want to report that 2.0.17 behaves identical.

@ChrGri
Copy link
Author

ChrGri commented Jul 8, 2024

@SuGlider I dont want to bother you, but is there something I can do to accelerate the investigation?

Btw. I see serial stall even with deactivated HID output after longer period of time. So serial over USB CDC alone seem to be sufficient to make the communication stall.

@SuGlider
Copy link
Collaborator

SuGlider commented Jul 8, 2024

When DTR is activated, by the second time, the S3 detects It as a "enter in boot mode", which is described in the Technical Reference Manual.

This state halts the processing and forces the S3 to enter in Boot Mode.

Arduino or any software loaded into the S3 can't change such behavior. This is a ROM functionality.

I think that it may be possible to burn an eFuse of the S3 to disable such behavior.

@SuGlider
Copy link
Collaborator

SuGlider commented Jul 8, 2024

There is a way to check if the S3 enters in Boot Mode by connecting another terminal application to the UART0 output and check the messages ROM will output when DTR is activated.

@ChrGri
Copy link
Author

ChrGri commented Jul 8, 2024

Thank you @SuGlider You already explained the RTS/DTR logic above. The remaining issue is, that the serial output stalls after a while, see #9582 (comment)

I initially thought that serial transmission only stalls, when CDC and HID output is activated, but it seams to stall when only CDC is activcated too.

@SuGlider
Copy link
Collaborator

SuGlider commented Jul 8, 2024

Would it be possible for you to post a basic sketch with detailed explanation in order to help me to reproduce the CDC stalling?

Thanks.

@ChrGri
Copy link
Author

ChrGri commented Jul 8, 2024

Would it be possible for you to post a basic sketch with detailed explanation in order to help me to reproduce the CDC stalling?

Thanks.

For sure. A sample script was posted here:
#9582 (comment)

@SuGlider
Copy link
Collaborator

SuGlider commented Jul 8, 2024

The issue is also only with CDC, right?
I understand that it is not necessary to use HID together with CDC.

How should I reproduce the CDC issue?

@ChrGri
Copy link
Author

ChrGri commented Jul 10, 2024

The issue is also only with CDC, right? I understand that it is not necessary to use HID together with CDC.

How should I reproduce the CDC issue?

I'll try to generate a simple code to reproduce the issue with CDC only. This will take some time though. In the meantime, I suggest looking into the sample code from above (HID + CDC) which will create the serial stall, when the delay call is removed:
image

Thank you

@ChrGri
Copy link
Author

ChrGri commented Jul 29, 2024

@SuGlider Did you had a chance to look into the HID+CDC example already?


Edit:
Btw. I tried the same example on a ESP32 S2 mini and it has the same problem.
image

@SuGlider
Copy link
Collaborator

Hi @ChrGri - I just returned from vacation. This is in my list of work. Please give me a week and I'll test it.

@ChrGri
Copy link
Author

ChrGri commented Jul 30, 2024

Then welcome back. Hope you had a good vacation too!

To make your life as easy as possible, I'll add a test description below.

  1. take ESP32 S2 mini or ESP32 S3 (other boards might behave similar)
  2. upload the software with simultaneous CDC and HID output from here
    https://github.com/ChrGri/DIY-Sim-Racing-FFB-Pedal/tree/develop/Validation/Joystick_Serial_test
  3. restart the ESP
  4. windows game controller output app to check the change in HID output
  5. open a serial monitor
  6. the ESPs output will stall now after a while, if not, please reduce the delay
    https://github.com/ChrGri/DIY-Sim-Racing-FFB-Pedal/blob/e2798eca295c65b02d2448eeabd65c69a27d08bd/Validation/Joystick_Serial_test/src/Joystick_Serial_test.ino#L54

The expected behaviour is that CDC and HID output streams are stable and don't collapse.

@ChrGri
Copy link
Author

ChrGri commented Aug 14, 2024

@SuGlider any updates?

@ChrGri
Copy link
Author

ChrGri commented Aug 22, 2024

@SuGlider Anything I can do to help?

@ChrGri
Copy link
Author

ChrGri commented Sep 1, 2024

@SuGlider it's been over a month since you replied. Can you confirm the issue from here?

@ChrGri
Copy link
Author

ChrGri commented Sep 7, 2024

The main issue was described. The cdc+hid issue will be tracked here.

@ChrGri ChrGri closed this as not planned Won't fix, can't repro, duplicate, stale Sep 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Needs investigation We need to do some research before taking next steps on this issue Type: Question Only question
Projects
None yet
Development

No branches or pull requests

2 participants