UDD_Send() (uotghs_device.c) has an unbounded busy-wait on TXINI — permanent MCU hang if host doesn't set it (native USB CDC line-state related)

[MrLeftarion]

Summary

UDD_Send() in system/libsam/source/uotghs_device.c contains an unbounded busy-wait loop with no timeout, waiting for the TXINI (Transmit IN complete) flag on the target endpoint. If the host does not set this flag (e.g. around a USB line-state change such as DTR/RTS toggling on the native CDC port), the MCU hangs permanently in this loop, with interrupts still enabled and no way to recover except a full reset/power cycle.

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;

    while( UOTGHS_DEVEPTISR_TXINI != (UOTGHS->UOTGHS_DEVEPTISR[ep] & UOTGHS_DEVEPTISR_TXINI )) {}
    ...

(https://github.com/arduino/ArduinoCore-sam/blob/master/system/libsam/source/uotghs_device.c)

This is called from USBD_Send() in USBCore.cpp, which is the underlying function used by every SerialUSB.write()/println() call (via Serial_::write in CDC.cpp), as well as HID reports.

Related but similarly unbounded waits exist elsewhere in the same file (UDD_WaitIN, UDD_WaitOUT, UDD_WaitForINOrOUT) — all are plain while(...); with no timeout or bail-out condition.

How I found this

I have an Arduino Due (genuine, Rev3) that reliably hangs during extended native-USB operation on specific Windows 11 hosts (newer Intel xHCI controllers — Tiger Lake/Alder Lake generation). Full investigation history, including USB traffic capture (Wireshark/USBPcap) and elimination of third-party software as a cause, is documented here: #71 (comment)

Using an ST-Link V2 + OpenOCD + GDB attached via the DEBUG (SWD) header, I was able to halt the MCU while it was hung (native USB unresponsive, but the rest of loop() — an independent LED blink — still running, i.e. not a full lockup: DHCSR.S_LOCKUP was 0, core was in normal Thread mode with interrupts enabled).

Register/symbol dump at the hang:

pc = 0x00081b06   -> inside UDD_Send+18
lr = 0x00080e99   -> called from USBD_Send() at USBCore.cpp:204
xpsr = 0x01000000 -> Thread mode, not inside an ISR
primask/faultmask = 0 -> interrupts not disabled

info line *0x00080e99 resolved cleanly to USBCore.cpp:204 inside USBD_Send, confirming the call chain Serial_::write → USBD_Send → UDD_Send, stuck spinning on the TXINI wait with no way out.

Reliable(-ish) repro

A minimal sketch (no HID/Joystick needed, plain CDC is enough):

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());
  }
}

• Left running for ~15-25 minutes on an affected Windows 11 host: hangs organically.
• Faster/more reliable trigger: from the host, open the native CDC COM port via .NET System.IO.Ports.SerialPort without setting DtrEnable/RtsEnable to true before .Open() — this toggles the CDC line state in a way that reliably triggers the hang within seconds in my testing.
• Does not reproduce on Linux or in Windows Safe Mode on the same physical hardware — consistent with the theory that it's a host-timing-dependent race on whether TXINI gets set before the firmware's next attempt to send.

Suggested direction for a fix

At minimum, every unbounded while(...) wait in uotghs_device.c (UDD_Send, UDD_WaitIN, UDD_WaitOUT, UDD_WaitForINOrOUT) should have a bounded timeout (e.g. based on millis() or a cycle counter) and return an error/abort the transfer instead of spinning forever when the expected hardware flag never arrives. I understand this changes the function signatures/call sites (currently void/unconditional uint32_t return used as byte count, not status) — happy to discuss/help test a patch if a maintainer can advise on the preferred approach (e.g. optional timeout parameter, or a global "USB write timeout" behavior similar to how other Serial implementations use setTimeout()).

Environment

• Board: Arduino Due (genuine, Rev3, native USB port)
• Core: Arduino SAM Boards (32-bit ARM Cortex-M3), package version installed via Boards Manager — 1.6.12
• Debug setup: ST-Link V2 (clone) via the onboard 4-pin SWD DEBUG header, OpenOCD 0.12.0, arm-none-eabi-gdb 4.8.3 (bundled with Arduino IDE's SAM toolchain)
• Host: Windows 11 (build 26100), Intel USB 3.10/3.20 xHCI controllers (PCI\VEN_8086&DEV_51ED, PCI\VEN_8086&DEV_461E)

Happy to provide more register dumps, the .elf/.map files, or the full Wireshark capture if useful.

[MrLeftarion]

Update: patch tested, root cause confirmed, plus a separate host-side finding

I wrote and tested a patch based on the analysis above. Sharing results in case it's useful, along with an important caveat discovered during extended testing.

The patch

1. Timeout guard in UDD_Send (uotghs_device.c): added a millis()-based 5ms timeout to the while(TXINI...) busy-wait, returning 0 instead of blocking forever.
2. Bounds checking added to UDD_Send, UDD_Recv, UDD_Send8, UDD_Recv8 (if (ep >= MAX_ENDPOINTS) return ...;), plus a defensive clamp directly in the udd_get_endpoint_fifo_access8(ep) macro itself (uotghs_device.h) so any other/future direct macro use is also protected.
3. USBD_Send (USBCore.cpp) updated to check UDD_Send's return value and abort the remaining transfer on timeout instead of silently advancing the buffer pointer as if the bytes had been sent (the original code ignored the return value entirely, which was safe originally since UDD_Send never returned without succeeding — but became unsafe once (1) introduced a real failure path).

A second, distinct bug found via SWD debugging

While testing patch (1) with an ST-Link + OpenOCD + GDB attached via the DEBUG header, I caught a separate, genuine HardFault (not just a busy-wait), fully independent of the TXINI issue:

CFSR = 0x00008200  (PRECISERR + BFARVALID — synchronous BusFault)
HFSR = 0x40000000  (FORCED — escalated to HardFault)
BFAR = 0x20200000  (exact same value across two separate occurrences)

Backtrace showed the fault inside UDD_Recv(), called from USB_ISR() (USBCore.cpp:648), while the main loop was innocuously executing UARTClass::available()/serialEventRun() — i.e. an interrupt fired mid-loop and crashed inside the USB ISR.

The BFAR value is explainable: udd_get_endpoint_fifo_access8(ep) computes UOTGHS_RAM_ADDR + ep * 0x8000. With UOTGHS_RAM_ADDR = 0x20180000, 0x20200000 − 0x20180000 = 0x80000, and 0x80000 / 0x8000 = 16. So ep = 16 at the fault site — not random stack garbage, but a suspiciously round number (0x10), which made me suspect a bitmask (e.g. an UOTGHS_DEVISR_PEP_x-style interrupt-pending bitmask, where bit 4 = 0x10) being used directly as an endpoint index somewhere instead of being decoded into the bit position first. I wasn't able to pin down the exact call site with the source I had access to (would need the full USBCore.cpp/uotghs_device.c side by side to trace it precisely) — the macro-level clamp in point (2) above is a blunt but effective mitigation regardless of where the bad ep originates.

After applying both patches, this exact HardFault (identical BFAR) has not reproduced again in several long-running tests (multiple hours each), including one overnight run — though given how long it originally took to reproduce, I can't yet call this conclusively fixed, just no longer observed.

Important caveat: a separate, host-side (Windows) issue remains

During one of the long test runs, SerialUSB output stopped appearing in both the Arduino IDE Serial Monitor and an independent .NET SerialPort PowerShell script — for several hours, with no crash on the device side. I attached GDB with a breakpoint directly on UDD_Send() and confirmed, across many consecutive breakpoint hits over several minutes, that the device was still calling UDD_Send(ep=3, ...) successfully every 5 seconds as expected, with TXINI set correctly (DEVEPTISR[3] == 0x00050000 every time, matching all previously-observed healthy states) — i.e. the firmware was working correctly and had no idea anything was wrong.

Meanwhile, on the Windows side:

• Get-PnpDevice showed the port as Status: OK.
• Opening the port via .NET SerialPort.Open() threw IOException: "The device attached to the system is not functioning." (ERROR_DEVICE_NOT_FUNCTIONING).
• Disabling/re-enabling the specific PnP device via Disable-PnpDevice/Enable-PnpDevice did not restore it.
• Only a full physical USB cable disconnect/reconnect (forcing a fresh enumeration) restored the connection.

So at least some of the "hang" symptoms I originally attributed to the device turned out to be a separate, host-side (Windows USB stack) issue — the device was working fine, but Windows had gotten the CDC endpoint into a state it couldn't recover from without a full physical re-enumeration. I'm noting this here for completeness/honesty, since it means not every symptom in my original report is necessarily attributable to the firmware bug — but the two firmware bugs above (unbounded TXINI wait, and the ep-related BusFault) are real, independently confirmed via register-level debugging, and the patch does prevent the device itself from crashing.

Happy to open a PR with the patch if useful — let me know if you'd want it structured differently (e.g. a proper timeout return-value contract across the UDD_* API rather than the minimal patch I did).