Arduino Due SerialUSB bug on monitor close/USB unplug

[drianMC]

Hi all,
I'm trying to develop an application where the arduino Due is continuously working (always powered), and I can connect to it using the native USB, so I can get data about the process. I have found unexpected behavior of the Due board when it is unplugged, or the serial port is closed.
For the following test I have used this Arduino Code. With this one two different problems are observed.

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  SerialUSB.begin(115200);
}
void loop() {
  SerialUSB.print("H");
  SerialUSB.print("e");
  SerialUSB.print("y");
  SerialUSB.print(" ");
  SerialUSB.print(":");
  SerialUSB.println(")");
  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(200);                       // wait for a second
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
  delay(200);                       // wait for a second
}

I have found this issues
->If Serial monitor is closed while sending data through the native USB (SerialUSB) the main loop gets freezed, until the serial monitor is opened again. (With the test code, it can be observed that the led stops blinking).
->If unplugged the Native USB while sending data (and keep powered with the other USB), when a new monitor is opened, the received data order is changed. How can it be? The data order gets changed, and while unplugged the led stops blinking.

I also found a post where one of the bugs is mentioned:
https://forum.arduino.cc/index.php?topic=560839.0
As Sanworks_J explains this problem only appears when the computer used as serial monitor is Windows 10. I have check both problems in Linux, and in this case the board works correctly.

I have followed this Steps to in the second issue.
-->Connect both the programming USB (just for power, no data) and Native USB.
--> Upload the sketch to the board, and open the serial monitor, native USB. (Data received correctly).
--> While serial monitor is opened, unplug the Native USB (while powered with the other USB)
--> Plug the Native USB again. Close the monitor opened before(because it is stopped).
--> Open a new serial monitor, and the received data from that moment the data order is wrong.

Since that moment, the received messages are as follows.

)eH y):H
ye: 
)eH y):H
ye:

When it should be:

Hey :)
Hey :)
Hey :)

I have made this test in different PCs and with different Arduino Due boards, with the same results in Win10. When used Linux it doesn't happen, but the program gets stopped when unplugged the USB, this problem remains in Linux.
Any possible solution to this issue?

Thanks in advance.

[SparkApplicationMaster]

+1, I have this issue too:
->If Serial monitor is closed while sending data through the native USB (SerialUSB) the main loop gets freezed, until the serial monitor is opened again. (With the test code, it can be observed that the led stops blinking).
Using Arduino Due and Windows 10

[iddq]

What if you set timeout by SerialUSB.setTimeout()?

[drianMC]

After some time I have been trying again to find the reason of this issue.

What if you set timeout by SerialUSB.setTimeout()?

I didn´t notice any change using that function, seems not to affect to this issue.

Using the VisualMicro for debugging, I found that the blocking function is UDD_Send, in the "uotghs_device.c" file.
The first part of the function can the modified by adding a time limit to the while loop, this doesn´t solve the real problem, but at least doesn´t freeze the main loop.

uint32_t UDD_Send(uint32_t ep, const void* data, uint32_t len)
{
	const uint8_t *ptr_src = data;
	uint8_t *ptr_dest = (uint8_t *) &udd_get_endpoint_fifo_access8(ep);
	uint32_t i;

	uint32_t beginTime =GetTickCount();            //<-- Added
	TRACE_UOTGHS_DEVICE(printf("=> UDD_Send (1): ep=%lu ul_send_fifo_ptr=%lu len=%lu\r\n", ep, ul_send_fifo_ptr[ep], len);)
	while( UOTGHS_DEVEPTISR_TXINI != (UOTGHS->UOTGHS_DEVEPTISR[ep] & UOTGHS_DEVEPTISR_TXINI )) {
		if( (millis()-beginTime)>5 ){	     //<-- Added
			break;                      //<-- Added
		}                                    //<-- Added
	}
...
}

With this timeOut the USB can be unplugged while sending data via USB without suffering a lock.

This file is found in the following folder:
[Disk]:\Users[UserName]\AppData\Local\Arduino15\packages\arduino\hardware\sam\1.6.12\system\libsam\source\uotghs_device.c

This file had to be included as "Source Files" in Visual Studio project to be used. When using the Arduino IDE it seems like the other file was used. I would appreciate if someone could explain me how to make the Arduino IDE to use this modified file, as I only achieved to make it work with the Visual Sutio, referencing the file as a source file.

[tinoest]

I would appreciate if someone could explain me how to make the Arduino IDE to use this modified file, as I only achieved to make it work with the Visual Sutio, referencing the file as a source file.

You need to rebuild the libsam_sam3x8e_gcc_rel.a object file found in the .arduino15/packages/arduino/hardware/sam/1.6.12/variants/arduino_due_x ( or equivalent location on your machine )

On a mac I go to .arduino15/packages/arduino/hardware/sam/1.6.12/system/libsam/build_gcc then ensure that the ARM_GCC_TOOLCHAIN is set to .arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/ ( or equivalent location on your machine ) then make clean, make which should rebuild that object for you.

[iddq]

Great job, Thank you!
I hope this patch will be accepted although it seems to me the Due code has not been maintained for a long time.
https://forum.arduino.cc/t/serialusb-can-block-upon-write-has-no-availableforwrite-method/415576/8

[drianMC]

Thanks @tinoest for the explanation about rebuilding the object file. I am having some issues trying to rebuild the object.
As I am using millis(), it seems not to be able to make the file, it can be used with the sketch compilation, but not for the build of the sam object itself. It might be changed for another timeOut method like the one used in the thread shared by @iddq , just attempt times, not limited by time.

[MrLeftarion]

I can confirm this bug still reproduces on a genuine Arduino Due, current Arduino SAM core, on Windows 11 (build 26100). Same symptom: loop() freezes (LED stops toggling) tied to native USB CDC port open/close/line-state changes, host-side. Not specific to the Joystick/HID library — reproduces with a plain CDC-only sketch as well. Does not reproduce on Linux or in Windows Safe Mode on the same physical hardware.

Environment

• Board: Arduino Due (genuine, Rev3, native USB port used)
• Core: Arduino SAM Boards (Cortex-M3), 1.6.12
• IDE: Arduino IDE 2.3.10
• Host OS where the bug reproduces: Windows 11 (build 26100), Intel USB 3.10/3.20
  xHCI host controllers (PCI\VEN_8086&DEV_51ED, PCI\VEN_8086&DEV_461E)
• Host OS where the bug does NOT reproduce on the same physical machine:
  • Windows 11 Safe Mode (minimal, no third-party drivers loaded)
  • Live Ubuntu (USB passthrough disabled, direct boot from USB flash drive) on
    the exact same laptop/hardware
• Also does NOT reproduce on a second Windows 11 laptop with an older Intel chipset
  (PCI\VEN_8086&DEV_9D2F, Skylake/Kaby Lake era USB 3.0 xHCI controller)

A few additional data points that might help narrow it down:

1. Two distinct failure modes observed, seemingly depending on timing:

• Full MCU hang: LED completely stops, board totally unresponsive.
• USB-only hang: LED keeps blinking normally (so loop() is still running!), but the CDC/HID interface stops responding and Windows reports Device Manager error 43.

2. Faster, more reliable repro via DTR/RTS: opening the native CDC port from a .NET host app (System.IO.Ports.SerialPort) without first setting DtrEnable/RtsEnable to true before calling .Open() causes the .Open() call itself to hang on the host, and shortly after, the board fully hangs. With DtrEnable = true; RtsEnable = true; set before .Open(), this particular immediate-hang path was avoided, but the board still eventually hung later during extended operation — so DTR/RTS state seems to be a trigger, not the whole story.

3. Wireshark/USBPcap capture of a "natural" (extended-runtime) hang: right before the freeze, normal URB_BULK in traffic on the CDC IN endpoint (0x83) was ongoing every ~5s as expected. The last successful bulk transfer was followed by a gap, then the host issued URB_FUNCTION_SYNC_RESET_PIPE_AND_CLEAR_STALL twice in a row on that endpoint (Windows' recovery attempt after the endpoint stopped responding). Importantly, no unusual EP0 control transfer (no SET_LINE_CODING, SET_CONTROL_LINE_STATE, etc.) was seen immediately before the device stopped responding in that particular capture — so in that instance the device seems to have gone unresponsive on its own, not strictly as an immediate reaction to a host command. This might indicate a race between line-state handling and normal ongoing USB IN traffic, rather than a simple "close = hang" causality alone.

4. Host chipset dependency: on my end this is fully reproducible (~15-25 min of uptime, or much faster via the DTR/RTS trick above) on a laptop with a newer Intel xHCI controller (Tiger Lake/Alder Lake generation, PCI\VEN_8086&DEV_51ED / DEV_461E), but does not reproduce at all on a second Windows 11 laptop with an older Intel chipset (DEV_9D2F, Skylake/Kaby Lake-era xHCI), same OS build. This suggests sensitivity to exact USB transaction timing from the host controller, on top of whatever the underlying DTR/line-state race is.

5. Ruled out as sole causes on the affected machine: spacedesk, Kaspersky, VirtualBox's VBoxUSBMon, MSI Afterburner/RTCore drivers, all third-party services (Clean Boot via msconfig), USB Selective Suspend/LPM. None of these were required for the hang to occur — points back to this being a core USB/CDC stack issue rather than a third-party driver conflict.

Given @drianMC's finding that this is Windows-specific and reproducible across different PCs/boards, plus the DTR/RTS angle above, it seems worth looking at how CDC.cpp/USBCore.cpp handle SET_CONTROL_LINE_STATE / SET_LINE_CODING relative to ongoing bulk IN transfers — possibly a race where a line-state change interrupts/corrupts in-flight endpoint state. I don't have a fix, but I have a minimal repro sketch and can gather more data (I'm planning to attempt SWD-level debugging with an ST-Link to catch the exact hang state on UOTGHS registers, will report back if I get useful register-level data).

Minimal repro sketch (no Joystick/HID needed):

bool state;
uint32_t Tim;
uint32_t TimLog;

void setup() {
  pinMode(13, OUTPUT);
  delay(1000);
  SerialUSB.println(1);
}

void loop() {
  if (millis() - Tim >= 500) {
    Tim = millis();
    digitalWrite(13, state);
    state = !state;
  }
  if (millis() - TimLog >= 5000) {
    TimLog = millis();
    SerialUSB.println(millis());
  }
}