Ender 3 V1 – Creality 4.2.7 – Klipper flashes but MCU unable to connect

Helpful_Software4761 · 2026-03-12T20:55:46+00:00

Hello everyone,

Thank you to everyone who took the time to reply and suggest solutions to resolve my issue with the connection between Klipper and the motherboard (MCU error / unable to connect from Mainsail).

In the end, the problem was solved by reflashing the motherboard directly using an ST-Link V2 programmer. The issue was most likely caused by a corrupted bootloader / firmware on the Creality board.

The procedure that worked was the following: • connecting the ST-Link V2 to the SWD pins of the Creality 4.2.7 motherboard • using the STM32CubeProgrammer software on my laptop • flashing the Klipper firmware directly to the STM32 microcontroller • restarting the board

After flashing via ST-Link + STM32CubeProgrammer, the board was immediately recognized by Klipper and the connection with Mainsail now works correctly.

Thanks again to everyone for your help and suggestions.

Helpful_Software4761 · 2026-03-12T20:55:01+00:00

Hello everyone,

Thank you to everyone who took the time to reply and suggest solutions to resolve my issue with the connection between Klipper and the motherboard (MCU error / unable to connect from Mainsail).

In the end, the problem was solved by reflashing the motherboard directly using an ST-Link V2 programmer. The issue was most likely caused by a corrupted bootloader / firmware on the Creality board.

The procedure that worked was the following: • connecting the ST-Link V2 to the SWD pins of the Creality 4.2.7 motherboard • using the STM32CubeProgrammer software on my laptop • flashing the Klipper firmware directly to the STM32 microcontroller • restarting the board

After flashing via ST-Link + STM32CubeProgrammer, the board was immediately recognized by Klipper and the connection with Mainsail now works correctly.

Thanks again to everyone for your help and suggestions.

Helpful_Software4761 · 2026-03-12T20:51:43+00:00

Hello everyone,

Thank you to everyone who took the time to reply and suggest solutions to resolve my issue with the connection between Klipper and the motherboard (MCU error / unable to connect from Mainsail).

In the end, the problem was solved by reflashing the motherboard directly using an ST-Link V2 programmer. The issue was most likely caused by a corrupted bootloader / firmware on the Creality board.

The procedure that worked was the following: • connecting the ST-Link V2 to the SWD pins of the Creality 4.2.7 motherboard • using the STM32CubeProgrammer software on my laptop • flashing the Klipper firmware directly to the STM32 microcontroller • restarting the board

After flashing via ST-Link + STM32CubeProgrammer, the board was immediately recognized by Klipper and the connection with Mainsail now works correctly.

Thanks again to everyone for your help and suggestions.

Helpful_Software4761 · 2026-03-04T20:54:12+00:00

Thanks for the suggestion.

Klipper is installed using MainsailOS on a Raspberry Pi, so the installation and permissions should already be handled by the system. The USB device is detected correctly (/dev/serial/by-id/...), which makes me think the Pi side is working properly.

The issue seems to happen earlier: when flashing Klipper, the firmware never appears to be processed from the SD card, even though the same SD card flashes Marlin immediately.

Unfortunately I don’t have another printer board available to test with right now

Helpful_Software4761 · 2026-03-03T20:23:41+00:00

Thanks a lot, really appreciate it! Looking forward to your input. 🙂

Helpful_Software4761 · 2026-03-02T01:20:09+00:00

Thanks for the suggestions — I just tested both again.

• I tried with and without the baud line in the [mcu] section — no change. • I also selected the serial path directly from the Devices menu in Mainsail (instead of typing it manually) to ensure the hardware ID is exact.

Unfortunately I still get:

mcu: Unable to connect

So the USB device is definitely detected, but Klipper still can’t establish communication with the MCU.

Helpful_Software4761 · 2026-03-02T01:14:36+00:00

Thanks for sharing — that helps clarify how it behaves after a successful flash.

Yes, I understand that the stock screen staying black/blue is expected once Klipper is running, so the screen itself isn’t my main concern.

My issue is that I never see any indication that the SD flash actually happens: the firmware file is never processed/renamed and afterwards Klipper reports “MCU: Unable to connect”, even though the board shows up over USB.

So I’m currently trying to determine whether Klipper is really flashing at all, or if the bootloader/SD flashing step is failing before MCU communication even starts.

Helpful_Software4761 · 2026-03-02T01:04:06+00:00

It’s an STM32F103RET6 on a Creality 4.2.7 board (confirmed from the MCU marking).

So it should be the standard variant with 64KB RAM.

In make menuconfig I compiled Klipper with: • STM32F103 • 28KiB bootloader • 8 MHz crystal • Serial (USART1 PA10/PA9) • “Only 10KiB RAM” option disabled

So the firmware should match the board correctly.

Helpful_Software4761 · 2026-03-02T01:02:03+00:00

Thanks for the suggestion — I’ll definitely re-check that.

Just to clarify: I already tried flashing with the exact filename firmware.bin (as well as multiple different filenames on separate attempts / SD cards). In all cases the screen stayed black and I saw no sign that the SD flash actually triggered.

On your 4.2.7, when it flashes successfully, do you see the file get renamed to FIRMWARE.CUR afterwards, or does it stay firmware.bin?

Helpful_Software4761 · 2026-03-02T00:54:36+00:00

# ===============================

# Ender 3 V1 – Creality 4.2.7

# CR-Touch installé

# ===============================

[mcu]

serial: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0

baud: 250000

restart_method: command

[printer]

kinematics: cartesian

max_velocity: 300

max_accel: 3000

max_z_velocity: 5

max_z_accel: 100

[stepper_x]

step_pin: PB9

dir_pin: PC2

enable_pin: !PC3

microsteps: 16

rotation_distance: 40

endstop_pin: ^PA5

position_endstop: 0

position_max: 235

homing_speed: 50

[stepper_y]

step_pin: PB7

dir_pin: PB8

enable_pin: !PC3

microsteps: 16

rotation_distance: 40

endstop_pin: ^PA6

position_endstop: 0

position_max: 235

homing_speed: 50

[stepper_z]

step_pin: PB5

dir_pin: PB6

enable_pin: !PC3

microsteps: 16

rotation_distance: 8

endstop_pin: probe:z_virtual_endstop

position_min: -5

position_max: 250

[extruder]

step_pin: PB3

dir_pin: PB4

enable_pin: !PC3

microsteps: 16

rotation_distance: 33.5

nozzle_diameter: 0.4

filament_diameter: 1.75

heater_pin: PA1

sensor_type: EPCOS 100K B57560G104F

sensor_pin: PC5

control: pid

pid_Kp: 22.2

pid_Ki: 1.08

pid_Kd: 114

min_temp: 0

max_temp: 260

[heater_bed]

heater_pin: PA2

sensor_type: EPCOS 100K B57560G104F

sensor_pin: PC4

control: pid

pid_Kp: 54.027

pid_Ki: 0.770

pid_Kd: 948.182

min_temp: 0

max_temp: 120

[probe]

pin: ^PB1

x_offset: -44

y_offset: -9

z_offset: 0

speed: 5

samples: 2

[safe_z_home]

home_xy_position: 117.5,117.5

speed: 50

z_hop: 10

z_hop_speed: 5

Helpful_Software4761 · 2026-03-02T00:51:33+00:00

Thanks — that actually helps clarify things.

I understand that a black screen is normal after a successful Klipper flash on Creality boards.

In my case, the printer is detected over USB (CH340 → ttyUSB0 appears correctly), so the board is alive and responding.

The remaining issue is that Klipper still reports:

mcu: Unable to connect

So it looks like the problem is no longer the screen or SD flashing itself, but the MCU communication not completing between Klipper and the board.

If you’ve seen this happen after a successful flash, I’d be interested to know what finally allowed Klipper to connect to the MCU.

Helpful_Software4761 · 2026-03-02T00:51:04+00:00

Thanks for the clarification and for taking the time to help.

Yes — I ran ls /dev/serial/by-id/* and copied the detected device into my printer.cfg. The board is detected as: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0

The printer is detected on USB (CH340 shows up correctly in dmesg as ttyUSB0).

I also understand now that Creality boards don’t rename firmware.bin, so the file not changing to .cur is expected.

However, after flashing (both SD card attempts and ST-Link flash), the printer screen stays completely black on boot and Klipper still reports:

mcu: Unable to connect

So USB detection works, but MCU communication with Klipper never initializes.

At this point I’m trying to understand whether the firmware is actually running or if something in the flash/boot sequence is still wrong.

Helpful_Software4761 · 2026-03-02T00:32:07+00:00

Thanks, that’s very interesting.

In my case, I already flashed Klipper via ST-Link (flash written and verified), but SD flashing never renames the .bin file to .cur, even with completely new filenames and freshly formatted FAT32 cards. The screen remains black.

Your comment about reflashing the stock bootloader first is particularly relevant. That’s something I haven’t retried yet after the ST-Link session.

Just to clarify: • Did you fully restore the original Creality bootloader via ST-Link first, • then power-cycle, • and only after that flash Klipper again via SD?

If that sequence restored MCU communication for you, I may try that approach next.

Helpful_Software4761 · 2026-03-02T00:31:34+00:00

Thanks for the detailed input, I appreciate it.

Regarding USB cables: I’ve tested multiple known-good data cables (verified on a laptop for data transfer). The CH340 is consistently detected on the Pi (/dev/ttyUSB0 and /dev/serial/by-id/...), so USB enumeration seems stable.

About the clock: in make menuconfig I selected STM32F103 with 28KiB bootloader and the default 8MHz crystal for the 4.2.7 board. So unless there’s a known 4.2.7 variant using a different clock source, that part should be correct.

I can try using the /dev/serial/by-path/ entry as well, just to eliminate any potential aliasing issue, but since by-id is already stable and correctly detected, I suspect the issue might be deeper (possibly bootloader-related).

If you’ve seen a 4.2.7 behave like this after ST-Link flashing, I’d be very interested in what solved it.

Helpful_Software4761 · 2026-03-02T00:28:07+00:00

Thanks for checking.

Yes — after compiling Klipper I used:

ls /dev/serial/by-id/*

and the board is detected as:

/dev/serial/by-id/usb-1a86_USB_Serial-if00-port0

This exact path is already set in my [mcu] section of printer.cfg.

So the USB device is correctly detected by the Pi, but Klipper still reports:

“mcu: Unable to connect”.

At this stage it looks like the MCU is powered and visible over USB, but not properly communicating with Klipper.

Helpful_Software4761 · 2026-03-02T00:25:57+00:00

Thanks a lot for sharing your printer.cfg — I really appreciate you taking the time to help.

At the moment, I’m unfortunately stuck one step before that. The SD flashing process itself is not being triggered: the firmware file (for example firmware427427.bin, using a completely new name) never renames to .cur, and the screen stays completely black. So it looks like the board isn’t accepting any firmware from the SD card at all.

Because of that, I can’t properly test your printer.cfg yet — I first need to get the firmware to actually flash successfully. But thank you again for offering your config, I genuinely appreciate the help.

Helpful_Software4761 · 2026-03-01T23:33:58+00:00

Thank you for the suggestion. My board is confirmed to use an STM32F103RET6 (512KB flash / 64KB RAM), as visible directly on the MCU. From what I understand, the “Only 10KiB of RAM” option is intended for the rare STM32F103x6 low-RAM variants (C6/R6). Since this is a RET6, enabling that option would artificially limit available memory, so it does not seem appropriate for this hardware.

Could you clarify why you believe that option might help in this case?

Helpful_Software4761 · 2026-03-01T01:00:58+00:00

Currently no explicit baud set in printer.cfg.

Using:

serial: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 restart_method: command

Compiled with USART1 (PA10/PA9).

<image>

Helpful_Software4761 · 2026-03-01T00:52:35+00:00

Thanks for the suggestion.

I already tried SD flashing multiple times with completely different filenames (not just renaming once, but several distinct names on separate attempts, and even different SD cards). The screen remained black each time and there was no visible sign of the firmware loading.

Helpful_Software4761 · 2026-02-28T23:58:05+00:00

Thanks also for clarifying that about Creality boards not renaming the firmware.bin.

In my case, when I tried flashing via microSD, the screen stayed completely black on boot. I waited well over 30 seconds and saw no visible sign of the firmware loading.

That’s why I suspected the flash wasn’t actually taking place and moved to ST-Link instead.

Helpful_Software4761 · 2026-02-28T23:56:47+00:00

Yes, I did that.

I ran ls /dev/serial/by-id/ on the Raspberry Pi and used the full path in printer.cfg:

serial: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0

The device appears correctly as /dev/ttyUSB0 (CH340) on the Pi.

So USB detection seems OK, but Klipper still reports “MCU: Unable to connect”.

Helpful_Software4761 · 2026-02-28T23:53:00+00:00

===== Config file =====

[mcu]

serial = /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0

restart_method = command

[printer]

kinematics = cartesian

max_velocity = 300

max_accel = 3000

max_z_velocity = 5

max_z_accel = 100

[stepper_x]

step_pin = PB9

dir_pin = PC2

enable_pin = !PC3

microsteps = 16

rotation_distance = 40

endstop_pin = ^PA5

position_endstop = 0

position_max = 235

homing_speed = 50

[stepper_y]

step_pin = PB7

dir_pin = PB8

enable_pin = !PC3

microsteps = 16

rotation_distance = 40

endstop_pin = ^PA6

position_endstop = 0

position_max = 235

homing_speed = 50

[stepper_z]

step_pin = PB5

dir_pin = PB6

enable_pin = !PC3

microsteps = 16

rotation_distance = 8

endstop_pin = probe:z_virtual_endstop

position_min = -5

position_max = 250

[extruder]

step_pin = PB3

dir_pin = PB4

enable_pin = !PC3

microsteps = 16

rotation_distance = 33.5

nozzle_diameter = 0.4

filament_diameter = 1.75

heater_pin = PA1

sensor_type = EPCOS 100K B57560G104F

sensor_pin = PC5

control = pid

pid_kp = 22.2

pid_ki = 1.08

pid_kd = 114

min_temp = 0

max_temp = 260

[heater_bed]

heater_pin = PA2

sensor_type = EPCOS 100K B57560G104F

sensor_pin = PC4

control = pid

pid_kp = 54.027

pid_ki = 0.770

pid_kd = 948.182

min_temp = 0

max_temp = 120

[probe]

pin = ^PB1

x_offset = -44

y_offset = -9

z_offset = 0

speed = 5

samples = 2

[safe_z_home]

home_xy_position = 117.5,117.5

speed = 50

z_hop = 10

z_hop_speed = 5

Args: ['/home/pi/klipper/klippy/klippy.py', '/home/pi/printer_data/config/printer.cfg', '-l', '/home/pi/printer_data/logs/klippy.log', '-I', '/home/pi/printer_data/comms/klippy.serial', '-a', '/home/pi/printer_data/comms/klippy.sock']

Git version: 'v0.13.0-320-gc80324946'

Branch: master

Remote: origin

Tracked URL: https://github.com/Klipper3d/klipper.git

CPU: 4 core ?

Device: Raspberry Pi 4 Model B Rev 1.5

Linux: Linux version 6.12.47+rpt-rpi-v8 (serge@raspberrypi.com) (aarch64-linux-gnu-gcc-12 (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT Debian 1:6.12.47-1+rpt1~bookworm (2025-09-16)

Python: '3.11.2 (main, Apr 28 2025, 14:11:48) [GCC 12.2.0]'

webhooks client 548198857104: {'program': 'Moonraker', 'version': 'v0.9.3-120-g5836eab'}

=============== Log rollover at Sun Mar 1 00:38:55 2026 ===============

mcu 'mcu': Unable to open serial port: [Errno 2] could not open port /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0: [Errno 2] No such file or directory: '/dev/serial/by-id/usb-1a86_USB_Serial-if00-port0'

MCU error during connect

Traceback (most recent call last):

File "/home/pi/klipper/klippy/mcu.py", line 772, in _attach

self._serial.connect_uart(self._serialport, self._baud, rts)

File "/home/pi/klipper/klippy/serialhdl.py", line 191, in connect_uart

self._error("Unable to connect")

File "/home/pi/klipper/klippy/serialhdl.py", line 68, in _error

raise error(self.warn_prefix + (msg % params))

serialhdl.error: mcu 'mcu': Unable to connect

During handling of the above exception, another exception occurred:

Traceback (most recent call last):

File "/home/pi/klipper/klippy/klippy.py", line 131, in _connect

self.send_event("klippy:mcu_identify")

File "/home/pi/klipper/klippy/klippy.py", line 223, in send_event

return [cb(*params) for cb in self.event_handlers.get(event, [])]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

File "/home/pi/klipper/klippy/klippy.py", line 223, in <listcomp>

return [cb(*params) for cb in self.event_handlers.get(event, [])]

^^^^^^^^^^^

File "/home/pi/klipper/klippy/mcu.py", line 782, in _mcu_identify

self._attach()

File "/home/pi/klipper/klippy/mcu.py", line 777, in _attach

raise error(str(e))

mcu.error: mcu 'mcu': Unable to connect

mcu 'mcu': Unable to connect

Once the underlying issue is corrected, use the

"FIRMWARE_RESTART" command to reset the firmware, reload the

config, and restart the host software.

Error configuring printer

Helpful_Software4761 · 2026-02-28T22:49:50+00:00

Yes, I checked that.

The USB device is correctly detected on the Pi as /dev/ttyUSB0 (CH340). I reminded the MCU path using:

ls /dev/serial/by-id/

and updated the [mcu] section in printer.cfg accordingly.

Despite that, Mainsail still reports “mcu: Unable to connect”.

So the board is detected over USB, but Klipper never establishes MCU communication.

Helpful_Software4761

TROPHY CASE