Transition to shutdown state: MCU 'mcu' shutdown: Timer too close
Ive searched around and some people have a hot pi when this happens - I dont think I have. Can anyone help me solve this problem?
My small amount of understanding results in this graph from the klippy.log by using graphstats.py after reboot, showing the cpu is not overloaded. So I installed htop to view the proceses and I'm surpriosed to see ffmpeg using 50% cpu, im guessing thats for the webcam. Otherwise Im stumped to the cause.
9 Replies
what size and brand of SD card are you using?
Unsure but I think its a U10 32GB - does my graph indicate that could be an issue?
https://discord.com/channels/582187371529764864/1118265360701984921 might be good to read
Thanks - Ive had a read - but there are so many rabbit holes to go down with this 'Timer too close' how do you know its the SD card at fault - does the graph tell you that?
The graph shows nothing, which is why I am guessing it's the SD card
When I say rabbit holes I’m referring to the error message:
“excessive CPU time, high swap usage, disk errors, overheating, unstable voltage, or similar system problems on the host computer.”
So I need to ‘work the problem’ and consider each:
Disc - I’m gonna assume my SD card is an Extreme because I didn’t cheap out building this machine-can’t get behind it right now.
Temperature? Doubt that too because I’ve had this error before and pi had not been throttled - ( there is a Linux tool to check that can be run through ash whilst in the error screen)
- excessive CPU time-that may be my problem due to the 50% fmpeg - I’ll try lowering frame rate and observe
- high swap usage- dunno how to test that
- disk errors - surely that data is in klippy or some log we can graph?
- overheating - I don’t have a fan but
- unstable voltage-nope I have a seperate power supply for pi
- or similar system problems on the host computer.-?? Say what?
I’m surprised I haven’t found a thread on this whole topic and also that there isn’t a graphing tool for all the related variables in the logs which would enable quick analysis rather than trial and error
So I tried changing the webcam framerate, ands restarted it and weirdly the ffmpeg process disappeared. No more 50% CPU loading. I wonder if there is a bug in the timelapse module causing this excess after a print finishes. I keep the htop process running and observe after print stops.
During fmpeg timelapse processing
After: ( no big process) I ran that timelapse render manually so jury is still out until next big print finishes (tomorrow) and the auto render happens.
