MKS Robin: MCU 'mcu' shutdown: Timer too close

General Discussion
1

Basic Information:

Printer Model: Hypercube Evolution
MCU / Printerboard: MKS Robin V2.2 (OG, NOT nano) 3x TMC2209, 1x TMC2100, Rpi 3 B+, Raspicam capped at 10fps
klippy.log (1.2 MB)

Describe your issue:

My Printer works fine for hours, even days none stop printing. But suddenly had this happen 2x times now:

While checking mainsail in Browser, it suddenly resets with following error while klippy.log shows nothing:

MCU 'mcu' shutdown: Timer too close
This often indicates the host computer is overloaded. Check
for other processes consuming excessive CPU time, high swap
usage, disk errors, overheating, unstable voltage, or
similar system problems on the host computer.
Once the underlying issue is corrected, use the
"FIRMWARE_RESTART" command to reset the firmware, reload the
config, and restart the host software.
Printer is shutdown

I already replaced USB-Cable with High Quality one including ferrit-core. Also reduced baud to 115200. My board uses 8mhz crystal and firmware is flashed accordingly. My board uses a CH341 usb controller.

What is the reason for this?

Next thing I’ll test is to reduce microsteps of steppers and enable interpolation, maybe I overload the STM32F103ZET6 with true 256 microsteps?

1 Like
2

This should be the case…

4

So far no issues with microsteps: 32
2nd 10-hour print just completed.
If this really is the case as it seems, this is really bad error-handling from klipper side.

I believe on marlin, if the microcontroller was behind, it was just spitting out warnings, not aborting the print, destroying the part and wasting hours of print time.

5

I had the same issue with my OrangePi and high µsteps. It was much better with the RasPi4.
The reason for this was handled in another thread if I remember properly…
But I think comparing Marlin with Klipper is not applicable. If the MCU is overloaded with Marlin you’ll see blobs during prints as it waits until the queue is processed.
Under Klipper such tasks will overload the RasPi or what ever you are using. I don’t know whether one could implement an exception handler that does not halt the MCU…

6

Thanks for your report. Observed the same problem with stm32f401 @ 256 microsteps, works fine at 64.