MCU goes to shutdown

General Discussion
1

Basic Information:

Printer Model: Voron 2.4
MCU / Printerboard: Fysetc Spider 2.2, BTT SB2209, Cartographer3D, BTT MMB
Host / SBC Raspberry Pi 3B+
klippy(3).log (298.1 KB)

Software: RaspberryPi OS Bookworm lite 64bit

klippy.log

Describe your issue:

My Voron was working quite well and I added an ECRFV2 with an BTT MMB 1.1. After this the mcu (Spider 2.2) goes to shutdown in the middle of a print.

The Spider is connected by USART, all other Boards are connected by CAN. Tried to connect the Spider by CAN too, but the same error occurs. CAN is set to 1000000baud and txqlen 256, USART is set to 250000. Board for CAN is a U2C 1.1 with Klipper-Bridge

Thought to have power issues and upgrades powersupply 24V from 200W to 350W, and added 50W 5V for the Raspberry.

After adding the ERCFv2, I upgraded the Software (from Buster to Bullseye) and my issues began. I tried Bookworm 32bit and 64bit. And finally I made a clean new software setup and redid all the cabeling… but I´m still getting these shutdowns.

After 3 weeks of trial and error… I am at the end of my knowledge.
There is no conclusive hint about why the spider shuts down.

1 Like
2

Your attached log does not contain any relevant error.

1 Like
3

That’s correct…

There is only the shutdown of the mcu which I don’t understand. No clue ist given by the log.

1 Like
4

The only “error” in your log is:

mcu.error: Can not update MCU 'mcu' config as it is shutdown

See Can not update MCU '<name>' config as it is shutdown

5

I read that topic. But restarting the firmware within a print is not a good option. Besides: When the error occurs, the only remedy is to restat the whole printer because just hitting “restart firmware” has no effect.

6

As stated in the linked topic: This message is the consequence of an error that happened earlier, but this error is not contained in your log.
As it stands, there is currently no further diagnosis possible.

7

I guess you have a cartographer problem like @Pitufo. You might read QUAD_GANTRY_LEVEL internal error.

8

Quite unlikely.
@WeissNicht stated it happened in the middle of the print. So most likely a Timer Too Close error after adding the MMU modifications.

In any case: The MMU modifications are known to not play well with Klipper and can be causing issues. As an unofficial modification, it is not supported.

Without a log showing the actual error, it’s all speculation.

9

Don’t know, I don’t use cartographer.

Though, the logs look quite similar.

WeissNicht

mcu 'toolhead': got {'oid': 18, 'next_clock': 3336443905, 'value': 2108, '#name': 'analog_in_state', '#sent_time': 1589.0000159140002, '#receive_time': 1589.100501612}
Loaded MCU 'cartographer' 67 commands (Cartographer 4.0.0 / )
MCU 'cartographer' config: ADC_MAX=4095 BUS_PINS_i2c1=PB6,PB7 BUS_PINS_spi1=PA6,PA7,PA5 CANBUS_FREQUENCY=1000000 CARTOGRAPHER_ADC_SMOOTH_COUNT=16 CLOCK_FREQ=48000000 MCU=stm32f042x6 PWM_MAX=2 RECEIVE_WINDOW=192 RESERVE_PINS_CAN=PA11,PA12 RESERVE_PINS_crystal=PF0,PF1 STATS_SUMSQ_BASE=256 STEPPER_BOTH_EDGE=1
mcu_temperature 'mcu' nominal base=-270.876494 slope=1305.179283
mcu_temperature 'toolhead' nominal base=-270.583090 slope=1313.265306
MCU error during connect
Traceback (most recent call last):
  File "/home/pi/klipper/klippy/klippy.py", line 135, in _connect
    cb()
  File "/home/pi/klipper/klippy/mcu.py", line 742, in _connect
    config_params = self._send_get_config()
                    ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/pi/klipper/klippy/mcu.py", line 728, in _send_get_config
    raise error("Can not update MCU '%s' config as it is shutdown" % (
mcu.error: Can not update MCU 'mcu' config as it is shutdown

Pitufo

mcu 'mcu': got {'oid': 17, 'next_clock': 2416730816, 'value': 19030, '#name': 'analog_in_state', '#sent_time': 13111.554150876, '#receive_time': 13111.842075751}
Loaded MCU 'cartographer' 67 commands (Cartographer 4.0.0 / )
MCU 'cartographer' config: ADC_MAX=4095 BUS_PINS_i2c1=PB6,PB7 BUS_PINS_spi1=PA6,PA7,PA5 CANBUS_FREQUENCY=1000000 CARTOGRAPHER_ADC_SMOOTH_COUNT=16 CLOCK_FREQ=48000000 MCU=stm32f042x6 PWM_MAX=2 RECEIVE_WINDOW=192 RESERVE_PINS_CAN=PA11,PA12 RESERVE_PINS_crystal=PF0,PF1 STATS_SUMSQ_BASE=256 STEPPER_BOTH_EDGE=1
mcu_temperature 'mcu' nominal base=-274.193548 slope=1320.967742
MCU error during connect
Traceback (most recent call last):
  File "/home/biqu/klipper/klippy/klippy.py", line 135, in _connect
    cb()
  File "/home/biqu/klipper/klippy/mcu.py", line 742, in _connect
    config_params = self._send_get_config()
  File "/home/biqu/klipper/klippy/mcu.py", line 728, in _send_get_config
    raise error("Can not update MCU '%s' config as it is shutdown" % (
mcu.error: Can not update MCU 'mcu' config as it is shutdown
10

There were no other errors. All the past logs had no issues besides the “mcu in shutdown” error.

BUT… i think I narrowed it down by accident. I ripped the cabeling for the caselights, which were controlled by led_effects. So I deactivated led_effects and was able to print 3 jobs withount any issue.
Maybe this was pure luck, but I guess, led_effects might have been flooding the interface to the spider (which was controlling the caselights). led_effects was there before, but I had to update it for the MMU (and the MMU produces additional traffic).

I will dig deeper into this.

by the way, Pitufu seems to use led_effects as well. So in that case cartographer produces a lot of traffic on the CANBus while QGL, in addition to led_effects having an effect active, which produces a lot of traffic too, this could lead to running out of bandwidth on the canbus

11

Another Printjob finished without any issues.

Afterwards I reactivated led_effects and after 3 min in the print…voilá shutdown.

I think this might be a strong indication what was going on there.

12

Entirely possible. Happy Hare and its macros are creating a lot of additional traffic / load.
Every action Klipper takes needs to be processed in a given time-frame. The more you put on it, the higher the chance that you push it over the brink and finally Timer Too Close errors occur

13

I don´t think it´s Happy Hare in my case. Happy Hare is on the CANBus while the Spider mcu ist on USART for now. But since the only change I made now is to deactivate led_effects and I did not experience the error again (and It happened in 100% of my print jobs before); I think led_effects was flooding the mcu, which was controling the caselights. And - i guess - because of this, the mcu wasn´t even able to tell us, why it collapsed.

On the other hand, Happy Hare uses led_effects too; If I understood correctly, all the effects are triggered and controlled by the host, so there is a lot of trafic for all these "bling-bling-"effects.

My last thought on this is, that it might happen with other plugins, which will create a lot of traffic.

Glad to have found the culprit as my next step would have been to rip out the spider and try a Leviathan or Octopus pro.

1 Like
14

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