>_C2CZ
Serverless · Self-Hosting · Security · Independent Ops

Klipper "MCU 'mcu' shutdown: ADC out of range" Fix

By Noah Lindqvist · C2CZ · 27 August 2026 · Last verified: 2026-08-27

MCU 'mcu' shutdown: ADC out of range is the Klipper shutdown you get when a heater's temperature sensor reads outside its configured range — the micro-controller's analog-to-digital converter reported a sample the config says cannot happen. It is the most common Klipper failure on machines with a loose or dead thermistor, and the console message that follows usually names the exact sensor and the range it violated.

I chased this one on a printer that printed fine for a year, then started shutting down mid-print on the second layer. The heater was fine, the firmware was fine — the thermistor connector had worked itself loose. This post walks the exact message, the three causes I've seen in the field, and the check order that finds the fault in minutes instead of evenings.

TL;DR

  • The message is a safety shutdown, not a config error. The MCU's ADC read a temperature outside the sensor's configured min_temp/max_temp, so Klipper stopped everything.
  • Cause #1 by far: the thermistor. Disconnected, loose, broken, or end-of-life — it reads as an open circuit, which lands outside the valid range.
  • Cause #2: the wrong sensor type in printer.cfg. A mismatched sensor_type (wrong NTC B-value, wrong beta table) makes a healthy thermistor read nonsense.
  • Fix order: read the clarify line, check the reported temperature, reseat and inspect the sensor, audit sensor_type + min_temp/max_temp, then FIRMWARE_RESTART.

The exact message

Klipper writes the shutdown reason into the console and the UI exactly like this (the wording comes from Klipper's own error-handling source):

MCU 'mcu' shutdown: ADC out of range
This generally occurs when a heater temperature exceeds its
configured min_temp or max_temp.
Once the underlying issue is corrected, use the "FIRMWARE_RESTART"
command to reset the firmware, reload the config, and restart the
host software.
Printer is shutdown

When Klipper can attach a diagnostic line, you also get which sensor and which range — this is a real example from the Klipper community forums:

MCU 'mcu' shutdown: ADC out of range
Sensor 'extruder' temperature -99.585 not in range 0.000:300.000

A reading of -99.6 °C is the fingerprint of an open thermistor: the ADC sees essentially no current through the divider, the lookup table extrapolates to a nonsense temperature, and the range check fires. In Klipper's source, the ADC out of range reason is registered with exactly that explanation — "this generally occurs when a heater temperature exceeds its configured min_temp or max_temp" — and the diagnostic line is built from the sensor's configured range (verified in klippy/extras/error_mcu.py and klippy/extras/adc_temperature.py, master branch).

Why Klipper shuts down instead of printing on

The ADC range check is a thermal-runaway guard. Klipper configures the MCU to sample each analog input against a min_value/max_value window; if the sample stays outside that window for the configured number of consecutive reads, the MCU shuts down rather than trust a sensor that just lied. A thermistor that reports -99 °C or 500 °C is not a sensor you want driving a heater — the firmware would otherwise happily run the heater flat out trying to reach a target it can never measure. The shutdown is the correct behavior. Fix the sensing path, never disable the check.

The three causes, ranked

1. Thermistor open or intermittent (most common). The connector on the hot end works loose from vibration, the glass bead's lead breaks at the crimp, or the sensor has drifted out of spec over years of thermal cycling. Elegoo's field guide for the Neptune 4 series names exactly this: the error appears when the hot-end or bed sensor reports an abnormal temperature, "the most likely cause is a damaged thermal sensor" or its wiring. Jaycar's Neptune 4 troubleshooting guide is blunter: the thermistor is "either not connected, or has reached end-of-life."

2. Wrong sensor type in printer.cfg. A common self-inflicted version: you replace the stock thermistor with an NTC 100K B3950 (Trianglelab or similar), update nothing, and the firmware keeps the old table — or you pick "Generic 3950" when the part is actually a different beta. The community forum thread "MCU 'mcu' shutdown: ADC out of range with fresh NTC 100K" ends with exactly that fix: use the correct table and values for the actual part. The sensor is healthy; the math in config is wrong.

3. Wiring or board fault (rarer). A chafed wire shorting to the heater or frame, a broken trace, or — after all wiring is confirmed good — a damaged ADC input on the MCU. The forums have a case where the ADC port itself was faulty and the fix was moving the thermistor to a free ADC pin. Treat this as the last stop, after the connector and the config audit.

Diagnose before touching anything

The clarify line already told you the sensor. Now look at the live reading, not the shutdown. Klipper's QUERY_ADC command reports the raw analog value for a configured ADC; check it against the healthy state:

# from the Klipper console or via gcode command
QUERY_ADC [adc_name]

In the temperature graph, a cold printer should read room temperature — 20–30 °C, not -99 and not 400. If the number is pinned at one extreme, the sensor path is open (or shorted). If it wobbles when you wiggle the thermistor wire, you have a connection fault — that wiggle test has found more loose crimps than any multimeter in my toolbox. Klipper's config-check documentation walks the same check: verify temperatures are being properly reported before trusting the machine.

The fix, step by step

Step 1 — reseat and inspect the sensor path. Power off. Unplug and replug the thermistor connector, check the crimps, and confirm the glass bead is seated in the heater block (not dangling against the frame). A wiggle test at this stage is free and definitive.

Step 2 — audit the sensor lines in printer.cfg. Keep your own pin assignments; the lines that decide the ADC math are sensor_type, pullup_resistor, and the temperature window:

# In [extruder] — keep your own step/dir/heater pins, audit these lines:
sensor_type: NTC 100K B3950   # must match the actual thermistor part
sensor_pin: PC4               # must match the board wiring
pullup_resistor: 4700         # board-specific: usually 4700 or 100000
min_temp: 0
max_temp: 300

# In [heater_bed] — same audit, bed thermistors are usually NTC 100K too:
sensor_type: NTC 100K B3950
sensor_pin: PC5
pullup_resistor: 4700
min_temp: 0
max_temp: 130

If you replaced the sensor, set sensor_type to the actual part's table. If the reading is out of range at room temperature, sensor_type is your first suspect — especially on a machine that printed fine before a hot-end swap.

Step 3 — restart and verify. Klipper's own guidance after fixing the cause is the FIRMWARE_RESTART command — "this is similar to a RESTART command, but it also clears any error state from the micro-controller":

FIRMWARE_RESTART

After it comes back, confirm the cold temperatures look sane, then run a controlled heat test: set the extruder to 200 °C and watch the graph climb smoothly. Only when the sensor tracks the heater do you start a print.

Key takeaway

MCU 'mcu' shutdown: ADC out of range is Klipper's thermal-runaway guard doing its job. Read the diagnostic line, look at the live temperature, check the connector, then audit sensor_type — in that order. The sensor is the suspect nine times out of ten, and the fix is a reseat or a one-line config correction, not a firmware rebuild.

Related reading on C2CZ: this is the same evidence-first debugging discipline as Nginx 499 Client Closed Request — read the exact line, identify the component that reported it, then change the narrowest thing. And like the Turso SERVER_ERROR 404 post, everything here is verified against real sources and reproductions, not guesswork. More troubleshooting on the C2CZ home page.

Sources

C2CZ

Hyper-specific engineering guides: Cloudflare Workers, Turso, self-hosting, network security, offensive security, independent operations.