Another MCU 'mcu' shutdown: Timer too close

Basic Information:

Printer Model: don’t ask
MCU / Printerboard: stm32f401 + duex5
klippy.log: klippy.zip (3.7 MB)

Describe your issue:

I get MCU 'mcu' shutdown: Timer too close a lot, somewhat randomly once in a few printing days, but sometimes every time it’s at the same-ish place in the executed gcode of the print; the last two examples in the log are like that. I don’t have anything actively running on the SBC except klipper and tail -F klippy.log over ssh, plain Armbian on Cubieboard. No cron jobs. Reducing microstepping didn’t help.

How can i troubleshoot it further?

The typical reasons and causes are listed here: Timer too close

In the context of “Timer too close” this does not seem a wise thing to do.

Yes, i’ve read that post and couldn’t find anything relevant to my problem.

Why not? It’s just displaying one line a second, i am sure this doesn’t take much valuable CPU time and can be scheduled well.

  • You are using a modified Klipper version both in terms of the host version and the firmware part. If related to your issue is unknown and nobody here will follow up on such a version
  • So you are saying that you have already excluded all the reasons listed, e.g. SD card that is beginning to die, unstable voltages, additional USB devices, additional processes going rampant etc etc? If so, then maybe related to your modified version

This command is aggressively trying to get access to the file (-F) and returns every change. In the context of timing issues on the host, it is at least not what I would do. YMMV

The only modification to the running code is Independant acceleration limits for X and Y axes - #18 by Piezo

Yes.

I think you don’t understand how inotify works, and regardless, we can both see that it doesn’t impact CPU consumption much, if at all measurable. Besides, /tmp lives on tmpfs, so it can’t even introduce iowaits.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.