UNO R4 WiFi USB CDC serial communication randomly stops after several hours on Windows 11

[hatch222]

I am experiencing a long-term USB CDC serial communication problem with two Arduino UNO R4 WiFi boards.

After several hours of continuous Serial output, the Serial Monitor randomly stops receiving data.

The RA4M1 sketch itself continues running. The built-in LED continues toggling once per second even when Serial communication has stopped.

In some cases, the following message appears immediately before the Serial communication stops:

E (...) TUSB:DCD: Unknown Condition

Environment

• Windows 11
• Arduino IDE 2.3.10
• Arduino UNO R4 Boards core 1.6.0
• Serial: 115200 baud
• Two UNO R4 WiFi boards tested
• One UNO R4 used for comparison
• USB selective suspend disabled
• USB Root Hub / Generic USB Hub power-management options disabled
• A similar Serial stall has also occurred on another Windows notebook PC

Minimal test sketch

void setup()
{
  Serial.begin(115200);
  pinMode(LED_BUILTIN, OUTPUT);
}

void loop()
{
  static unsigned long count = 0;

  Serial.print("TEST ");
  Serial.println(count++);

  digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));

  delay(1000);
}

Test results

I ran two UNO R4 WiFi boards (A and B) and one UNO R4 (C) simultaneously using the same 1-second Serial test.

Both UNO R4 WiFi boards experienced repeated Serial communication stalls.

Examples:

UNO R4 WiFi A:

TEST 51160
E (51203238) TUSB:DCD: Unknown Condition

Serial stopped after approximately 14 hours 12 minutes.
The LED continued toggling.
Closing and reopening Serial Monitor restored communication.

The same UNO R4 WiFi later stopped again after approximately 35 hours 33 minutes at:

TEST 127964

Closing and reopening Serial Monitor again restored communication.

UNO R4 WiFi B stopped after approximately 26 hours 39 minutes at:

TEST 95919

Closing and reopening Serial Monitor restored communication.

There were also earlier failures. In some earlier cases, resetting the RA4M1 did not restore Serial communication, but unplugging and reconnecting the USB cable did.

Comparison with UNO R4

The UNO R4 (C), running simultaneously on the same PC with the same test sketch, continued operating normally for more than 47 hours 28 minutes:

TEST 170925

No Serial communication failure occurred on this board during that period.

Effect of Serial interval

I also changed:

delay(1000);

to:

delay(10000);

With the 10-second interval, both UNO R4 WiFi boards and the UNO R4 operated for at least 22 hours 45 minutes without a failure.

Therefore, the probability of the problem may be related to the frequency of USB CDC activity, although one short Serial message per second is a very low data rate.

Since the RA4M1 application continues running when Serial communication stops, and the problem has been reproduced on two UNO R4 WiFi boards while the comparison UNO R4 continued running, I suspect the ESP32-S3 / TinyUSB CDC USB bridge path.

Is this a known issue with the UNO R4 WiFi USB bridge/TinyUSB implementation?

Is there any additional diagnostic test I can perform?

[Paul_KD7HB]

@hatch222

!digitalRead(LED_BUILTIN));

What does DigitalRead return if there is nothing in the buffer to read? Check the documentation, please.

Edit;; Forget the comment, I was thinking data communication, not a digital pin read.

[horace]

just ran the code of post 1 on a UNO R4 WiFi same IDE, UNO R4 core, etc

started at 11.31 failed at 15.09 LED sill blinking

11:31:04.412 -> TEST 0
11:31:05.380 -> TEST 1
11:31:06.389 -> TEST 2
11:31:07.376 -> TEST 3
11:31:08.411 -> TEST 4
11:31:09.412 -> TEST 5
11:31:10.406 -> TEST 6
11:31:11.412 -> TEST 7
....

15:09:23.916 -> TEST 13066
15:09:24.916 -> TEST 13067
15:09:25.921 -> TEST 13068
15:09:26.939 -> TEST 13069
15:09:27.948 -> TEST 13070
15:09:28.937 -> TEST 13071
15:09:28.937 -> E (13175735) TUSB:DCD: Unknown Condition

if I close the IDE and reopen it still no Serial Monitor output

maybe worth asking on the UNO R4 forum

[gilshultz]

@hatch222

After several hours of continuous Serial output, the Serial Monitor randomly stops receiving data.

I have seen similar problems with the IDE. For some reason, the computer re-enumerates the USB device and changes the port assignment.

I discovered this by running several copies of the IDE, with each one set to a different USB port. When one Serial Monitor quit receiving data, another one started. Some data was lost during the changeover.

I eventually chased the problem back to a bad USB cable.

You might check whether the USB port assignment is changing when the Serial Monitor stops receiving data, and try a different known-good USB cable.

[horace]

@gilshultz

I have seen similar problems with the IDE. For some reason, the computer re-enumerates the USB device and changes the port assignment.

in the test of post 3 the COM port did not change - post still open in Serial Monitor IDE just no output after (the LED is still blinking at 17.27)

15:09:28.937 -> E (13175735) TUSB:DCD: Unknown Condition

Windows Device Manager says

[gilshultz]

I am assuming the blinking LED you are describing is the TX LED. If it continues blinking after the Serial Monitor stops receiving data, that may indicate the Arduino is still transmitting. Also how is this project powered?

I would troubleshoot this one step at a time:

1. Try a different known-good USB cable and see if the problem still occurs.
2. Using the same computer and cable, use a separate serial terminal program such as PuTTY instead of the Arduino Serial Monitor. See if the problem still occurs.
3. If it still fails, move the Arduino and the same USB cable to another computer and repeat the test.
4. Is the other Windows computer also running Windows 11? If possible, repeat the test on a computer using a different operating system.

Change only one thing at a time and let each test run long enough for the problem to normally occur. This should help determine whether the problem follows the Arduino, USB cable, Arduino IDE, or computer.

[kenb4]

If you don't have a separate terminal program, it's likely that you have Python installed -- it's used in some Arduino tooling. So you can run a simple program to print the output. The AI generated this plausible version:

import serial

# Configure settings (Adjust port name and baudrate for your hardware)
PORT = 'COM4'          # Windows: 'COMx' | Linux: '/dev/ttyUSB0' or '/dev/ttyACM0'
BAUDRATE = 115200      # Match your device's speed (e.g., 9600, 115200)
TIMEOUT = 3            # Prevents hanging indefinitely if no data arrives

# Open port and read incoming data
with serial.Serial(PORT, BAUDRATE, timeout=TIMEOUT) as ser:
    print(f"Listening on {PORT}...")
    try:
        while True:
            # Read a full line up to a newline character (\n)
            line = ser.readline()
            
            if line:
                # Decode bytes to a string and strip whitespace
                print(line.decode('utf-8', errors='ignore').strip())
                
    except KeyboardInterrupt:
        print("\nStopping reader.")

Paste that into, say, serial-mon.py. (Be sure it is saved as "ANSI" and not UTF-16.) Make sure pyserial is installed, and run it. This is what I got, including that encoding mistake, using PowerShell in the Windows Terminal program.

PS E:\> gcb > serial-mon.py # alias for Get-Clipboard
PS E:\> notepad .\serial-mon.py # tweak the variables
PS E:\> python .\serial-mon.py
SyntaxError: Non-UTF-8 code starting with '\xff' in file E:\serial-mon.py on line 2, but no encoding declared; see https://python.org/dev/peps/pep-0263/ for details
# the error is due to the Byte Order Mark, U+FEFF little-endian, at the start of the file
# now re-Save-As with ANSI encoding, to remove the BOM
PS E:\> python .\serial-mon.py
Traceback (most recent call last):
  File "E:\serial-mon.py", line 1, in <module>
    import serial
ModuleNotFoundError: No module named 'serial'
PS E:\> pip install pyserial
Collecting pyserial
  Downloading pyserial-3.5-py2.py3-none-any.whl (90 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 90.6/90.6 kB 1.3 MB/s eta 0:00:00
Installing collected packages: pyserial
Successfully installed pyserial-3.5

PS E:\> python .\serial-mon.py
Listening on COM4...
TEST 334
TEST 335

Ctrl-C to exit. This will help determine if it is purely a Serial Monitor/IDE error, or something with the OS/hardware/cables.

[horace]

@gilshultz

am assuming the blinking LED you are describing is the TX LED.

the LED being blinked is

digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));

which is on pin 13

@gilshultz

2. Using the same computer and cable, use a separate serial terminal program such as PuTTY instead of the Arduino Serial Monitor. See if the problem still occurs.

running using Teraterm terminal emulator - started at 06.13
EDIT: appears to have stopped about 11.00

TEST 9874
TEST 9875
TEST 9876
TEST 9877
TEST 9878
TEST 9879

if I close teraterm and reopen it the UNO R4 WiFi still appears to be running

TEST 17787
TEST 17788
TEST 17789
TEST 17790
TEST 17791
TEST 17792
TEST 17793
TEST 17794

could be a teraterm problem?

EDIT2: ran using RealTerm - stopped after couple of hours

TEST 4087
                                                                     
TEST 4088
                                                                     
TEST 4089
                                                                     
TEST 4090
                                                                     
TEST 4091
     

EDIT3 - PuTTY ran for aprox 7hours then stopped

TEST 23672
TEST 23673
TEST 23674
TEST 23675

if I close PuTTY and reopen it the UNO R4 WiFi is still running

TEST 24408
TEST 24409
TEST 24410

PuTTY stopped again after approx 4 hours (with message this time)

TEST 39217
TEST 39218
TEST 39219
TEST 39220
TEST 39221
E (39846728) TUSB:DCD: Unknown Condition

if I close and restart PuTTY the UNO R4 WiFi program is still running

TEST 59805
TEST 59806
TEST 59807
TEST 59808

above tests were using a UNO R4 WiFi (same as original post) - will try running same test on other dev boards

[gilshultz]

From your description, it sounds like a computer problem.

If you can get your hands on a logic analyzer (a cheap one is less than $10 on AliExpress) or an oscilloscope, connect it to the serial output of the Arduino. Then you can determine whether the data stream actually stops or if the problem is between the Arduino and the computer.

The test equipment needs to be connected in parallel with the terminal. Do not restart or reset anything when the problem occurs until you have checked the signal.

You may be able to do a basic test with a meter, although it will be much less accurate. First take a voltage reading with nothing being transmitted. This gives you a baseline reading. Then take another reading while data is being transmitted. When the serial output stops after several hours, take another reading and compare it with the first two readings.

When doing these tests, leave the test equipment connected. Connecting or disconnecting equipment after the failure occurs could cause something to reset and destroy the evidence you are looking for.

Since you have tried two UNO R4 boards and both are doing the same thing, while the counter continues to run, my first guess would be the computer or the USB communication rather than the main Arduino program.

The first thing we need to determine is where the communication is failing.

[horace]

the tests in post 8 which replicated the problem of post 1 were using a UNO R4 WiFi

same code still running on a UNO R4 Minima after approx 18.5 hours without problems

12:00:04.174 -> TEST 1
12:00:05.431 -> TEST 2
12:00:06.473 -> TEST 3
....
06:38:25.637 -> TEST 67101
06:38:26.642 -> TEST 67102
06:38:27.651 -> TEST 67103
06:38:28.669 -> TEST 67104

EDIT: update been running for 32.5hours

20:50:46.160 -> TEST 117270
20:50:47.113 -> TEST 117271
20:50:48.133 -> TEST 117272

same code still running on a UNO R3 after approx 22 hours without problems

08:55:33.994 -> TEST 0
08:55:35.467 -> TEST 0
08:55:36.456 -> TEST 1
....
06:40:41.257 -> TEST 78402
06:40:42.263 -> TEST 78403
06:40:43.261 -> TEST 78404

EDIT: update been running for 36hours

20:52:01.739 -> TEST 129544
20:52:02.745 -> TEST 129545
20:52:03.749 -> TEST 129546

same code still running on a esp32 after approx 22 hours without problems

09:03:32.463 -> TEST 0
09:03:33.445 -> TEST 1
09:03:34.472 -> TEST 2
....
06:42:08.079 -> TEST 77915
06:42:09.061 -> TEST 77916
06:42:10.063 -> TEST 77917
06:42:11.065 -> TEST 77918
06:42:12.066 -> TEST 77919

EDIT: update been running for 36hours

20:52:50.666 -> TEST 128958
20:52:51.687 -> TEST 128959
20:52:52.701 -> TEST 128960

looks like a problem with the UNO R4 WiFi
will try an oscilloscope on the UNO R4 WiFi to check if data is still transmitting

[horace]

@gilshultz

Then you can determine whether the data stream actually stops or if the problem is between the Arduino and the computer.

ran test on UNO R4 WiFi stopped after 3.3hours outputting to IDE Serial monitor

09:54:13.119 -> TEST 0
09:54:14.087 -> TEST 1
09:54:15.104 -> TEST 2
09:54:16.126 -> TEST 3
...
13:13:56.858 -> TEST 11955
13:13:57.842 -> TEST 11956
13:13:58.839 -> TEST 11957
13:13:59.862 -> TEST 11958

serial still running (Tx light blinking) and USB D- and D+ signals active

however, normal running printing to serial monitor D- and D+ looked like

when it had stopped (no serial monitor output) D- and D+ looked like

test setup using USB breakout modules

[BitSeeker]

Do you have one of those UART adapter boards (FTDI, CP2102, CH340)?

You could maybe try the same experiment connecting TX0/TX1 and using Serial1.

On the UNO R4 WiFi, the USB-C data lines connect to the native USB port on the onboard ESP32-S3 module. As you point out, the ESP32 module contains a firmware that provides a "bridge" between it and the Renesas MCU. There is also a bit of hardware in the form of a TXB0108 8-bit bidirectional logic-level translator chip in between, that translates between the 3.3V and 5V logic.

AI proposes that one possible cause may be that Windows could be shutting down the USB port (to the ESP32) due to power saving and therefore recommends to do as follows:

Go to your computer's Device Manager, locate the USB Root Hubs, open Properties -> Power Management, and uncheck "Allow the computer to turn off this device to save power."

Of course, the fact that your experiment ran for 47 hours on a Minima without a fail and your experiment with an ESP32 ran fine, does seem to raise suspicion about "the bit in between", i.e the bridge path.

[hatch222]

Thank you very much for doing these additional tests.

Your results are very interesting and are consistent with my tests.

I have tested two different UNO R4 WiFi boards, and both show the same problem after several hours.

I also tested with Tera Term instead of the Arduino IDE Serial Monitor, and the serial output still stopped, so it does not appear to be specific to the Arduino IDE Serial Monitor.

As a comparison, my non-WiFi UNO R4 ran the same 1-second test for more than 47 hours without stopping.

Also, when I changed the interval from 1 second to 10 seconds, both UNO R4 WiFi boards ran for more than 22 hours without stopping.

In my tests, when the serial output stops, LED_BUILTIN continues blinking, so the RA4M1 sketch is still running.

Your oscilloscope result is particularly interesting because D+ and D- remain active even after the Serial Monitor stops receiving data.

This seems to further narrow the problem to the USB communication path specific to the UNO R4 WiFi, possibly around the ESP32-S3 / TinyUSB CDC bridge, although I don't think we can conclude the exact cause yet.

Regarding the Windows USB power-saving setting, I have already disabled "Allow the computer to turn off this device to save power" for the USB Root Hub and Generic USB Hubs. I rebooted the PC after changing the settings, but the problem still occurred.

I don't currently have an FTDI, CP2102, or CH340 USB-UART adapter, so I cannot test Serial1 that way at the moment.

Thank you again for taking the time to reproduce and investigate this.

[horace]

@hatch222

I don't currently have an FTDI, CP2102, or CH340 USB-UART adapter, so I cannot test Serial1 that way at the moment.

testing UNO R4 WiFi Serial and Serial1 with following code

// UNO R4 MWiFi - Serial uses USB  Serial1 uses D1/TX and D0/RX

//#define LED_BUILTIN 2
void setup() {
  // Note the format for setting a serial port is as follows: Serial1.begin(baud-rate, protocol, RX pin, TX pin);
  Serial.begin(115200);
  delay(2000);
  Serial1.begin(115200);  //, SERIAL_8N1, RXD2, TXD2);
  pinMode(LED_BUILTIN, OUTPUT);
}

void loop() {
  static unsigned long count = 0;
  Serial.print("TEST ");
  Serial.println(count);
  Serial1.print("Serial1 TEST ");
  Serial1.println(count++);
  digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
  delay(1000);
}

ran for 5.5hours then stopped - Serial monitor output

07:10:20.304 -> TEST 0
07:10:21.312 -> TEST 2
07:10:22.277 -> TEST 4
07:10:23.324 -> TEST 6
07:10:24.327 -> TEST 8
....
12:54:02.209 -> TEST 20428
12:54:03.210 -> TEST 20429
12:54:04.245 -> TEST 20430
12:54:05.245 -> TEST 20431

although nothing on Serial Monitor USB looks like

LED blinking and Serial1 still outputting on PuTTY

Serial1 TEST 21606
Serial1 TEST 21607
Serial1 TEST 21608
Serial1 TEST 21609
Serial1 TEST 21610
Serial1 TEST 21611

maybe worth testing with different baud rates

in case the problem is the ESP32-S3 also running above code on a ESP32-S3-DevKitC-1
been running for 6hours

13:16:29.275 -> TEST 21591
13:16:30.262 -> TEST 21592
13:16:31.261 -> TEST 21593
13:16:32.241 -> TEST 21594
13:16:33.274 -> TEST 21595
13:16:34.277 -> TEST 21596

EDIT: changed loop() delay from 1000mSec to 500mSec - ran for 2.7hours -similar number of print outputs in half the time

13:23:40.324 -> TEST 0
13:23:40.828 -> TEST 1
13:23:41.319 -> TEST 2
13:23:41.822 -> TEST 3
......
16:06:38.377 -> TEST 19433
16:06:38.879 -> TEST 19434
16:06:39.382 -> TEST 19435
16:06:39.883 -> TEST 19436

Serial1 still running

Serial1 TEST 19983
Serial1 TEST 19984
Serial1 TEST 19985
Serial1 TEST 19986
Serial1 TEST 19987

[BitSeeker]

I dug out my UNO R4 and am running a similar experiment, except that I have slightly modified the above code by adding the following two lines to the top of void setup():

pinMode(40, OUTPUT);
digitalWrite(40, HIGH);

This pulls pin 40 (D21) HIGH which flips the switch on the TXB0108 to make it connect the USB-C port directly through to the RA4M1 instead of the ESP32. In this way we observe the output directly from the RA4M1 and bypass the ESP32. I will post the result tomorrow.

I did first try bridging the RA4M1 USB pads on the back with a blob of solder, but that did not work. There was no serial port, let alone any output, although the sketch was already uploaded. The output on the UART board connected to Tx/Rx still showed up. I also tried the shorting the last pin on the power strip to ground and pressing reset. That did make the serial port appear, but on trying to connect to it I got an error stating it was busy. There was no other session connected to it.

[horace]

tested code of post 14 (outputting to Serial and Serial1) on a UNO R4 WiFi with the baudrate changed from 115200 to 9600 (loop time 1000mSec)
ran for 15hours then stopped

16:14:54.568 -> TEST 0
16:14:55.546 -> TEST 1
16:14:56.615 -> TEST 2
16:14:57.623 -> TEST 3
...
08:18:49.088 -> TEST 55990
08:18:50.094 -> TEST 55991
08:18:51.130 -> TEST 55992
08:18:51.130 -> E (68142957) TUSB:DCD: Unknown Condition

although nothing on Serial Monitor USB looks like

Serial1 still running OK

Serial1 TEST 56160
Serial1 TEST 56161
Serial1 TEST 56162
Serial1 TEST 56163
Serial1 TEST 56164
Serial1 TEST 56165

UPDATE: in case the problem is the ESP32-S3 also testing post 14 code on a ESP32-S3-DevKitC-1 been running for 25hours - update running for 34hours

[horace]

tested code of post 14 (outputting to Serial and Serial1) on a UNO R4 WiFi with the baudrate changed from 115200 to 230400 (loop time 1000mSec)
ran for 8hours then stopped

08:32:04.786 -> TEST 0
08:32:05.789 -> TEST 1
08:32:06.789 -> TEST 2
08:32:07.800 -> TEST 3
....
16:40:00.427 -> TEST 29181
16:40:01.465 -> TEST 29182
16:40:02.457 -> TEST 29183
16:40:03.460 -> TEST 29184
16:40:03.460 -> E (98215477) TUSB:DCD: Unknown Condition

[BitSeeker]

Ok, so running around 24hrs both ports are still active:

I will now comment out the two lines I added to run it through the ESP32 to see whether my board suffers the same problem.

[BitSeeker]

So the second run continued successfully for approximately 24hrs as well. I am running that experiment again and setting pin 40 LOW in the code to make absolutely sure that its switched to the ESP32.

Since either way, the data goes through the TXB0108 multiplexer, the cause can't be the multiplexer either.

I feel that I should also point out that I am NOT running on Windows, so can't rule out the possibility that it is a Windows OS issue.

I did have a look at Tools -> Firmware Updater, which is the method used to update the bridge firmware on the R4 WiFi, in the hope of discovering what bridge firmware version this board has. Unfortunately that information seems not to be available. The 'Check Updates' feature tells me only that version 0.6.0 is available to install. There seems to be no way to compare the version this board has installed with what is installed on your board or any other board for that matter.

I think all the tests run so far seem fairly conclusive that the problem is not being caused by the native USB port of any particular MCU. If you have also tried a different USB cable and are still having the same problem, then I suppose you could try updating the bridge firmware to see whether the current version solves the problem.

[horace]

@BitSeeker

modified the above code by adding the following two lines to the top of void setup():

pinMode(40, OUTPUT);
digitalWrite(40, HIGH);

This pulls pin 40 (D21) HIGH which flips the switch on the TXB0108 to make it connect the USB-C port directly through to the RA4M1 instead of the ESP32.

tried adding the code as suggested to program of post 14

void setup() {
  pinMode(40, OUTPUT);
  digitalWrite(40, HIGH);
  Serial.begin(115200);
  delay(2000);

failed after 9 hours

17:17:09.569 -> TEST 0
17:17:10.574 -> TEST 1
17:17:11.616 -> TEST 2
17:17:12.580 -> TEST 3
..
02:25:22.783 -> TEST 32754
02:25:23.789 -> TEST 32755
02:25:24.796 -> TEST 32756
02:25:25.799 -> TEST 32757
02:25:26.805 -> TEST 32758
02:25:27.797 -> TEST 32759
02:25:27.797 -> E (32928382) TUSB:DCD: Unknown Condition

will try original code running using KBUNTU version of Linux as host PC