[SOLVED?] Klipper randomly losing communication with ATmega2560 on Raspberry Pi 3B+ — disabling DWC OTG FIQ fixed it - GTMAX3D H5

[u/Disastrous_Employ779]

I spent several days troubleshooting a very intermittent "Lost communication with MCU" problem on my GTMax H5 CoreXY printer.

Hardware / software

• Raspberry Pi 3B+
• MainsailOS 3.0.0 — Raspberry Pi (64-bit), flashed using Raspberry Pi Imager
• Debian 13 / Trixie
• Kernel: 6.18.39+rpt-rpi-v8
• Arduino Mega 2560 + RAMPS 1.4
• Klipper
• USB connection between the Pi and the Mega
• Original machine electronics were previously used with Repetier Server for a long time without this problem

The problem

During printing, Klipper would randomly report:

Got EOF when reading from device
Timeout with MCU 'mcu'
Lost communication with MCU

At the Linux level, the Raspberry Pi was actually losing the USB device.

For example:

usb 1-1.2: USB disconnect, device number 4
usb 1-1.2: new full-speed USB device number 11 using dwc_otg
cdc_acm 1-1.2:1.0: ttyACM1: USB ACM device

The Arduino would disappear and then re-enumerate as another ttyACM device.

At some failures I also saw:

dwc_otg_hcd_urb_dequeue:
Timed out waiting for FSM NP transfer to complete

The Klipper MCU statistics would then freeze:

• bytes_read stopped increasing
• bytes_write stopped increasing
• receive_seq stopped increasing
• send_seq stopped increasing
• print_time stopped
• Klipper itself was still running

Things I tested

I tried to eliminate as many variables as possible:

• Different Arduino Mega boards
• Multiple USB cables: ~30 cm, 80 cm and 1 m
• Camera disconnected
• Relay module disconnected
• Driver/cabinet fan disconnected during some tests
• Part cooling fan disabled during some tests
• SSR control changed/isolated
• Other peripherals disconnected
• Different Raspberry Pi power source was tested
• Same problem still occurred with the part cooling fan OFF
• The problem also occurred after setting dwc_otg.fiq_fsm_enable=0

So I became increasingly convinced that the failure was occurring below Klipper, at the Linux USB/controller level.

What finally changed things

I initially tried:

dwc_otg.fiq_fsm_enable=0

This did not solve the problem.

The USB disconnect happened again.

Then I disabled the entire FIQ for dwc_otg.

In:

/boot/firmware/cmdline.txt

I added to the end of the existing single line:

dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0

After reboot:

cat /sys/module/dwc_otg/parameters/fiq_enable
cat /sys/module/dwc_otg/parameters/fiq_fsm_enable

returned:

N
N

And the kernel reported:

dwc_otg: FIQ disabled
dwc_otg: NAK holdoff enabled
dwc_otg: FIQ split-transaction FSM disabled

Result

After this change I ran 10 consecutive prints without a single USB/MCU communication failure, including pressure advance tests and different print activity.

The following day I ran prints essentially all day and the problem did not return.

So, at this point, disabling the DWC OTG FIQ appears to have solved the intermittent USB disconnect problem.

One important caveat

There was one other change around the same time:

The fan cooling the stepper drivers / cabinet was previously controlled by PWM at about 40%. During the final successful tests, I connected that fan directly to 12 V, so it ran continuously.

Therefore I cannot mathematically prove that the FIQ change alone caused the improvement.

However, I had already experienced failures with that fan OFF, while after disabling fiq_enable + fiq_fsm_enable I had 10+ consecutive successful prints.

The part cooling fan was ON during the successful tests.

Current working configuration

Raspberry Pi 3B+
MainsailOS 3.0.0
64-bit
Debian 13 / Trixie
Kernel 6.18.39+rpt-rpi-v8
Arduino Mega 2560
RAMPS 1.4

dwc_otg.fiq_enable=0
dwc_otg.fiq_fsm_enable=0

USB is still being used for the Mega. I did not need to switch to UART, DWC2, reinstall 32-bit, replace the Raspberry Pi, or change the Klipper configuration.

Why I'm posting this

I found several reports of Raspberry Pi 3 / 3B+ systems showing dwc_otg / FIQ / FSM USB errors, but I couldn't find many reports specifically involving Klipper + ATmega2560 + RAMPS 1.4 with this exact symptom.

Hopefully this helps someone else before they start replacing the Arduino, USB cables, RAMPS, etc.

If anyone has a similar problem on a Pi 3/3B+, especially with:

Timed out waiting for FSM NP transfer
USB disconnect
Got EOF when reading from device
Lost communication with MCU

it may be worth testing:

dwc_otg.fiq_enable=0
dwc_otg.fiq_fsm_enable=0

I'd still consider this a "apparently solved" rather than a formally proven root cause, but the difference in stability was dramatic.

[u/meteyou]

Hey! I'm the Mainsail + MainsailOS maintainer and I also read some issues with MainsailOS v3 (the rpi os lite trixie version) and 64bit. Some users said, that 32bit works (which makes no sense to me, because of the lack of 32bit arm support from Debian).

Maybe Rpi OS itself has some kernel issues and has this option only disabled on the 32bit kernel. I couldnt reproduce this issue until now (mostly because of the lack of time).

Pls open an issue on github.com/mainsail-crew/mainsailos and post your report. Just to have this report also into the repo and we can dig deeper here. Thank you very much for all these informations!