# MCU shutdown after couple hours **URL:** \ **Category:** General Discussion\ **Created:** [March 3, 2025, 6:52pm UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319 "2025-03-03T18:52:29Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Wattie](https://avatars.discourse-cdn.com/v4/letter/w/e47774/32.png) [@Wattie](https://klipper.discourse.group/u/Wattie)\ **Post date:** [March 3, 2025, 6:52pm UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/1 "2025-03-03T18:52:29Z")
### Basic Information: Printer Model: Zero G Nebula MCU / Printerboard: SKR EZ V3 with BTT PI V2 Host / SBC klippy.log [klippy (8).zip](https://klipper.discourse.group/uploads/short-url/aYNgQWDtbh9m0P8p0vCFqsTnDav.zip) (1.8 MB) _Fill out above information and_ **_in all cases attach your_ `klippy.log` _file_** (use zip to compress it, if too big). _Pasting your_ `printer.cfg` _is **not** needed_ _ **Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there** _ ### Describe your issue: … Hi all, At a loss here and looking for assistance. between 1 two hours into a print i get the MCU communication error, all the time. Cant finish a print. This usually happens when I am printing ABS in long runs of +4 hours. Fail usually happens around 2 hours in. ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/1/b/1b5823e21f3a3a5c80164cb58169c1da81cc9940.png) Ran Graph Klipper Stats and it seems that my MCU is booting in and out for the entire print and at some point decides to shut down. In the graph it seems to overload to above 250% ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/2/a/2aea5ce5f16b6dd8588d46a895e52542a8cf8d7b.png) ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/2/7/2729fe6674d63d322bf1a3a30ae74e019eaf3991.png) ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/b/b/bbe67a2ec19d798ee1c83df6b8630e47dd56fcae.png) ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/c/c/cc9faad77ce1622762db42e36ac800a18f716d27.png) If I look at the Klippy log I can see that the MCU is awake and then resets, ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/7/f/7fffe62b9c0e583cc16478237aa11696b3ddd2d2.png) ![WhatsApp Image 2025-03-02 at 11.08.26_39b0a2f2](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/d/4/d45d33d28aa5b0350e041865c9547d7fc5b0ec3d.jpeg) Maybe I am looking at this wrong but this is how I am interpreting the data. **Running the following setup:** - SKR mini 24V powered by meanwell PSU - BTT PI V2 powered by meanwell PSU - 2x Bigtreetech Tmc 5160T Plus X and Y motor powered by separate 48V PSU - EBB36 running CANBUS - Beacon System is running in CANBUS CANBUS cable to EBB36 is shielded and shield is connected to meanwell -24V ---
**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\ **Post date:** [March 3, 2025, 8:23pm UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/2 "2025-03-03T20:23:25Z")
Your log only contains the `MCU 'mcu' shutdown: Missed scheduling of next digital out event` error, but not the one from your screenshot. In any case, both typically have quite similar reasons. Usually and unfortunately, they are tedious to diagnose, often due to subtle hardware instabilities or effects from third-party modifications. See: - [Timeout with MCU / Lost communication with MCU](https://klipper.discourse.group/t/timeout-with-mcu-lost-communication-with-mcu/6639) - [Missed scheduling of next digital out event](https://klipper.discourse.group/t/missed-scheduling-of-next-digital-out-event/14775) Edit: It makes sense to remove the modifications and upgrading Klipper to the latest Git version as it contains extended CAN diagnostics. A new log would be required after any changes. ---
**Author:** ![Wattie](https://avatars.discourse-cdn.com/v4/letter/w/e47774/32.png) [@Wattie](https://klipper.discourse.group/u/Wattie)\ **Post date:** [March 4, 2025, 6:09am UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/3 "2025-03-04T06:09:50Z")
Hi Sineos, You are correct. I get both messages regarding the MCU. must have mixed up the logs. but the behavior is the same. Upgraded to all latest versions and disabled KAMP to see if that is the issue but unfortunately same behavior. I am starting to think that the 5160T pro’s are the issue here as I also spotted two undervoltage alarms in the logs on X and Y. Going to double check the wiring. Thank you for thinking with me. ---
**Author:** ![Wattie](https://avatars.discourse-cdn.com/v4/letter/w/e47774/32.png) [@Wattie](https://klipper.discourse.group/u/Wattie)\ **Post date:** [March 4, 2025, 8:27pm UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/4 "2025-03-04T20:27:34Z")
rechecked all wiring. there was one suspect on the 5160T, replaced the ferrule of a motor wire to the X axis. Did another print which failed again an hour in with an EBB CAN error. Load utilization is still all over the place : ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/c/4/c441a7e245e8d079fd1f9d46576473a5ab953bf9.png) ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/6/a/6ae8b314b2509ca3eea4ac628b9c181789758561.png) [klippy (9).log](https://klipper.discourse.group/uploads/short-url/qIh6H2BEifIPvBygIsBPaNcGp7o.log) (6.6 MB) Klippy notes: No undervoltage alarm! so that ferrule must have caused some issues. ---
**Author:** ![3dcase](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/3dcase/32/7797_2.png) [@3dcase](https://klipper.discourse.group/u/3dcase)\ **Post date:** [March 5, 2025, 6:04am UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/5 "2025-03-05T06:04:10Z")
So ABS runs with a hot bed and a hotter hotend. When you run a colder material, does it run ok past the 2 hour mark every time? I am asking because I once had an issue with layer shifts at 1 to 2 hours in and it was the heat building up through all hardware and doing its worst on a stepper driver. Maybe you are facing something similar now but it is affecting another element? If you can catagorically eliminate heat, you are one step closer I think. ---
**Author:** ![Wattie](https://avatars.discourse-cdn.com/v4/letter/w/e47774/32.png) [@Wattie](https://klipper.discourse.group/u/Wattie)\ **Post date:** [March 5, 2025, 6:32am UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/6 "2025-03-05T06:32:14Z")
Have two separate stepper drivers for X and Y that are 48v fed. all electronics expect EBB, hotend, beacon and the actual motors are in the enclosure. The rest is nice and cool: ![WhatsApp Image 2025-03-02 at 11.08.26_39b0a2f2](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/d/4/d45d33d28aa5b0350e041865c9547d7fc5b0ec3d.jpeg) I do see the issue more and consistent with ABS and running a hot enclosure though. ---
**Author:** ![3dcase](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/3dcase/32/7797_2.png) [@3dcase](https://klipper.discourse.group/u/3dcase)\ **Post date:** [March 5, 2025, 7:48am UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/7 "2025-03-05T07:48:42Z")
In that case I suspect the EBB, which is probably mounted right against the extruder stepper which also gets hot? The coil cannot be the issue I think, as you are not using it during printing. ---
**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\ **Post date:** [March 5, 2025, 9:47am UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/8 "2025-03-05T09:47:42Z")
> [@Wattie](#): > > Load utilization is still all over the place : This is not indicative of an issue in the first place. What is an issue that according to the log, you are having `bytes_retransmit` as well as `bytes_invalid` in your communication. This points to either hardware issues or potentially kernel issues on the host. More on this [here](https://www.klipper3d.org/CANBUS_Troubleshooting.html). ---
**Author:** ![Wattie](https://avatars.discourse-cdn.com/v4/letter/w/e47774/32.png) [@Wattie](https://klipper.discourse.group/u/Wattie)\ **Post date:** [March 5, 2025, 3:22pm UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/9 "2025-03-05T15:22:16Z")
I suspect the EBB and CANBUS system as well ---
**Author:** ![Wattie](https://avatars.discourse-cdn.com/v4/letter/w/e47774/32.png) [@Wattie](https://klipper.discourse.group/u/Wattie)\ **Post date:** [March 5, 2025, 3:26pm UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/10 "2025-03-05T15:26:08Z")
I kept my eye out if Bytes\_invalid showed anything other than Zero (o). But the bytes\_retransmit thing, if that shows a value other than zero, there is an issue? I think the ''overload that you see on the screen is indeed not that indicative as the CB2 that I am using has 4 kernels. so hence it might show \> 100% Now running a script to see the memory and CPU values live from the host CB2. ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/7/c/7c0101dc17f5d8ac55358c73fe57f266c8b9e957.png) ---
**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\ **Post date:** [March 5, 2025, 3:53pm UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/11 "2025-03-05T15:53:05Z")
Look into your klippy.log. The above is not relevant. ---
**Author:** ![Wattie](https://avatars.discourse-cdn.com/v4/letter/w/e47774/32.png) [@Wattie](https://klipper.discourse.group/u/Wattie)\ **Post date:** [March 5, 2025, 4:20pm UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/12 "2025-03-05T16:20:35Z")
> [@Wattie](#): > > bytes\_retransmit I indeed see it now. bytes\_retransmit slowly creeps up from 0 to in the thousands during printing. ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/c/5/c5ce37c115704e3bd8ccd70bafcf2eb1cc69b552.png) So it is the EBB36 giving the issue here. interesting What could that be. ---
**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\ **Post date:** [March 5, 2025, 4:39pm UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/13 "2025-03-05T16:39:36Z")
> [@Sineos](#): > > This points to either hardware issues or potentially kernel issues on the host. More on this [here](https://www.klipper3d.org/CANBUS_Troubleshooting.html). Without wanting to sound rude, it would really help if you read the provided information and follow it. There is unfortunately no “press button A solution”. ---
**Author:** ![Wattie](https://avatars.discourse-cdn.com/v4/letter/w/e47774/32.png) [@Wattie](https://klipper.discourse.group/u/Wattie)\ **Post date:** [March 5, 2025, 4:44pm UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/14 "2025-03-05T16:44:12Z")
I understand. Thinking out loud in my last comment, not asking for press button A solution. But can understand how that can come across. anyways, I am reading up on your link on the Klipper site 👍 Do appreciate the assistance! ---
**Author:** ![hcet14](https://avatars.discourse-cdn.com/v4/letter/h/ecd19e/32.png) [@hcet14](https://klipper.discourse.group/u/hcet14)\ **Post date:** [March 5, 2025, 5:08pm UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/15 "2025-03-05T17:08:12Z")
> [@Wattie](#): > > I suspect the EBB and CANBUS system as well Could you please post a picture how you mounted your EBB? ---
**Author:** ![Wattie](https://avatars.discourse-cdn.com/v4/letter/w/e47774/32.png) [@Wattie](https://klipper.discourse.group/u/Wattie)\ **Post date:** [March 5, 2025, 5:31pm UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/16 "2025-03-05T17:31:29Z")
sure! ![IMG-20250305-WA0011](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/7/e/7e73d1d2656dadda7dfb5634fe1ccee9038b8b00.jpeg) ![IMG-20250305-WA0012](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/a/0/a0a5cf6ff346a6908188462e968426f4e6aa3518.jpeg) ![IMG-20250305-WA0013](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/b/e/be7862dcee235719f367194aeac9f8f4ea94de27.jpeg) ![IMG-20250305-WA0014](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/e/c/ec2225e221a89f5a151c0b5dd1615df4ee554550.jpeg) ---
**Author:** ![Wattie](https://avatars.discourse-cdn.com/v4/letter/w/e47774/32.png) [@Wattie](https://klipper.discourse.group/u/Wattie)\ **Post date:** [March 5, 2025, 6:26pm UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/17 "2025-03-05T18:26:50Z")
Found a discrepancy: Ran a query based on the documentation from the link Sineos sent. Query was to check qlen which should be not more than 128. Result shows qlen 1024. Lets see if that can be fixed. ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/3/e/3edf8dc3b977d20afaaf3cf9126e5e130322e2b4.png) ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/c/0/c035e88b4e2e279d59a8f6536a440e48cad6418b.png) ---
**Author:** ![hcet14](https://avatars.discourse-cdn.com/v4/letter/h/ecd19e/32.png) [@hcet14](https://klipper.discourse.group/u/hcet14)\ **Post date:** [March 5, 2025, 7:09pm UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/18 "2025-03-05T19:09:02Z")
> [@Wattie](#): > > sure! Thanks. I’ll get back on the weekend, cause I would like to go deeper on that (time). ---
**Author:** ![Wattie](https://avatars.discourse-cdn.com/v4/letter/w/e47774/32.png) [@Wattie](https://klipper.discourse.group/u/Wattie)\ **Post date:** [March 5, 2025, 7:36pm UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/19 "2025-03-05T19:36:55Z")
Thanks! much appreciated! ---
**Author:** ![Wattie](https://avatars.discourse-cdn.com/v4/letter/w/e47774/32.png) [@Wattie](https://klipper.discourse.group/u/Wattie)\ **Post date:** [March 6, 2025, 7:07pm UTC](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319/20 "2025-03-06T19:07:30Z")
I think my problem has been solved. It was indeed the bytes\_retransmit issue which was increasing incremental until the buffer was full and eventually shut down. Ran the same 4hour print and finished without issues. Checked the log, no incremental bytes\_retransmits **What did I do?** **Solution:** The CAN0 file was set to the following: **allow-hotplug can0 iface can0 can static bitrate 1000000 up ifconfig $IFACE txqueuelen 1024** According to the klipper database this should not be set at 1024 but max 128. SSH’d into the host, looked up the file and changed the text to the following according to Klipper troubelshooting database: \*\*allow-hotplug can0 iface can0 can static bitrate 1000000 up ip link set $IFACE txqueuelen 128 \*\* The above change seems to have solved my issue. Lucky me cause I was about to pull the CANBUS and run the hotend wired to the mainboard. Already had the wiring ready for it haha! Guess I get to use that for a new build. Thanks @Sineos for pointing me in the right direction!!! I hope everyone that sees this thread and has the same issue can fix it now. It was a very frustrating issue to find. [Next page](https://klipper.discourse.group/t/mcu-shutdown-after-couple-hours/22319.md?page=2)