EBB36 Won't Start Anymore: 5 V Feeding Backwards

My HevORT switches itself off after a quarter of an hour of idling. Until a certain day, it also came back up reliably afterwards. Then it stopped doing so: every time the 24 V came back on, Klipper hung during startup, and the toolboard only showed up once I pressed its RESET button. A cold start at the mains switch, on the other hand, worked fine.

The cause was not in the firmware or on the CAN bus, but in a wire I had run myself. On the way there I ruled out six hypotheses and one useless test – and those are the really interesting part.

• CoreXY printer (HevORT) running Klipper
• Mainboard: BTT Octopus
• Toolboard: BTT EBB36 (STM32G0B1) on the CAN bus, connected via a U2C adapter
• Eddy probe on USB, Raspberry Pi 4 as host
• Moonraker switches the 24 V power supply via a GPIO on the Pi; the relay sits on the mains side, not on the DC side.

The relevant part of moonraker.conf:

And a macro that switches off the 24 V after 15 minutes of idling:

"It always worked until today" – that was my starting point. Since then, the same picture after every 24 V cycle:

• Klipper hangs on startup.
• The toolboard is unreachable.
• It only responds after pressing RESET on the EBB36.
• If I switch the whole printer off and on at the mains switch instead, everything starts normally.

First the usual queries on the Pi: which nodes respond, what does Katapult say, what does the CAN interface look like?

In the hung state, the queries returned nothing. That looked dramatic at first, but – more on that shortly – it is the normal behavior of a node that has already been assigned a node ID.

I had backups of can0 and moonraker.conf, so I ran a git diff against the current state. Only one line was new: bound_services: klipper. I also noticed that restart-ms was 0 on the running interface, but 100 in the configuration file.

Instead of just running individual experiments, I drove the cycle remotely through Moonraker's power API and then queried printer/info each time to see whether Klipper reported ready:

To properly test the firmware and protocol hypotheses, I read both sides:

• Firmware: src/generic/canserial.c and src/stm32/fdcan.c. There you find can_filter(0, CANBUS_ID_ADMIN) – so the admin channel always stays in the hardware filter.
• Host: klippy/serialhdl.py. Klipper repeats SET_NODEID to the board's UUID for 90 seconds.

It didn't come from a log, but from simply looking: with the 24 V switched off, the LEDs on the toolhead kept glowing – and so did an LED on the EBB36 itself.

Before I got to the LEDs, I pursued a whole series of plausible explanations. Each of them could be refuted with a concrete observation.

1. Katapult is silently stuck in the bootloader

The idea: because of the quick off and on, Katapult with CONFIG_ENABLE_DOUBLE_RESET detects a double reset and stays in the bootloader instead of starting Klipper.

Refuted: after a reset, the query reported Detected UUID: …, Application: Klipper. So Klipper was running on the board. The empty responses before that were not a sign of a hung bootloader, but the normal behavior of a node with an assigned node ID – it simply doesn't show up in a search for unassigned nodes.

2. Backfeeding via the driven CAN bus

The idea: as long as can0 is up on the Pi, the U2C drives the bus lines and keeps the toolboard half alive through the CAN levels.

Refuted by the control run in the measurement series: with can0 up, the board came up just as it did with can0 down.

3. Residual charge – the off time is too short

The idea: the capacitors don't discharge far enough in 12 seconds.

Refuted: from the hung state, even a full minute without 24 V didn't help.

4. A stale node ID or hardware filter blocks reconnection

The idea: the board keeps a stale node ID or filters out the host's admin messages.

Refuted by the source code on both sides: in the firmware, the admin channel always stays in the filter, and the host repeats SET_NODEID to the UUID for 90 seconds. A running Klipper on the board would have heard that.

5. Bouncing relay on the DC side

Ruled out: the relay switches on the mains side.

6. Missing or wrong 120 Ω termination

That was my own suspicion.

Refuted: bus-errors 0, and the behavior was binary – either the board came up or it didn't. Bad termination shows up as errors on the bus, not as a clean either-or.

7. A test that couldn't tell anything apart

In between, there was also an ACK test with cansend and candump. In hindsight it was badly designed: it would have produced the same result for every one of the open hypotheses. A test that can't rule out any hypothesis only costs time.

At some point I had additionally fed 5 V into the 5 V pins of the Octopus – "to stabilize the voltage".

With the 24 V power supply switched off, this is what happens: the 5 V buck converter on the Octopus normally converts 24 V to 5 V. But if 5 V is applied externally at its output and the 24 V is missing at its input, the body diode of the high-side switching transistor conducts in reverse. This lifts the 24 V rail to a few volts – enough to not be zero. That voltage reaches the toolboard via the umbilical cable.

As a result, the STM32 on the EBB36 never really lost power. Without a true loss of voltage there is no power-on reset – the board didn't restart cleanly when the 24 V came back and got stuck in a state that only the RESET button could get it out of.

The LEDs that kept glowing were exactly this symptom: power where there shouldn't be any.

1. Removed the external 5 V feed at the Octopus.
2. Re-enabled the 15-minute shutdown (backup: printer.cfg.vor-idleon).

No firmware change, no new bus configuration.

The same test as in the measurement series: three runs, each with 12 seconds without 24 V, followed by a query through the Moonraker API.

• Before: 0 of 3
• After: 3 of 3, each ready after 8 seconds

• Flashing over CAN still fails at CONNECT – at 1 Mbit, 500 kbit and 250 kbit. My suspicion points toward USB Katapult.
• Sporadic toolboard dropouts during operation still occur. They are a different problem and not solved by this fix; my current suspicion is the board itself.
• Whether weeks of backfeeding damaged the toolboard's voltage converter, I don't know. So far that is only a suspicion.

And second: every additional feed "for stabilization" is a second path through which current can also flow in the wrong direction. A buck converter is not a diode in reverse.