MCU down?! mcu 'mcu': Unable to connect

Sovol SV08
1

Hello, friends of 3D printing! :slight_smile:

My Mianboard MCU is no longer recognised. After extensive personal research, I have now reached the end of my tether and am turning to the collective knowledge of this forum in the hope of finding a solution :slight_smile:

This is actually the last step I can think of before I finally despair.

I actually run Klipper Mainline on my SV08. Why ‘actually’? Klipper greeted me with the message that the MCU is no longer accessible (mcu “mcu”: Unable to connect).

System (EMMC flashed)

Host (aarch64, 64-bit)
OS: Debian GNU/Linux 11 (bullseye)
BTT-CB1 2.3.4 Bullseye with Linux 5.16.17-sun50iw9
Klipper v0.13.0-514

After quite a bit of research, I found out that my MCU can no longer be found in Linux either.

biqu@sovolsv08:\~$ ls /dev/serial/by-id/
usb-katapult_stm32f103xe_52FF6E067167485753191787-if00
usb-Klipper_rp2040_5044505930A3761C-if00
usb-Klipper_stm32f042x6_0F001400115330374E333320-if00
biqu@sovolsv08:\~$ lsusb
Bus 003 Device 004: ID 1d50:614e OpenMoko, Inc. stm32f042x6
Bus 003 Device 003: ID 1d50:614e OpenMoko, Inc. rp2040
Bus 005 Device 002: ID 1d50:6177 OpenMoko, Inc. stm32f103xe

Definition

SV08 Toolhead (STM32F103)

/dev/serial/by-id/usb-katapult_stm32f103xe_52FF6E067167485753191787-if00
lsusb: ID 1d50:6177 OpenMoko, Inc. stm32f103xe

Klipper Expansion Board (STM32F042)

/dev/serial/by-id/usb-Klipper_stm32f042x6_0F001400115330374E333320-if00
lsusb: ID 1d50:614e OpenMoko, Inc. stm32f042x6

BTT Eddy (RP2040)

/dev/serial/by-id/usb-Klipper_rp2040_5044505930A3761C-if00
lsusb: ID 1d50:614e OpenMoko, Inc. rp2040

SV08 Mainboard (STM32F103) - missing, added manually for the forum

from my printer.cfg: stm32f103xe_30FFD7053347543032621651-if00

Now, to be on the safe side, I wanted to update the mainboard’s firmware to the same version, as I only installed Eddy Duo yesterday (wired and flashed, that’s all that’s possible at the moment). I connected to the mainboard using an St-Link v2 and the STM32CubeProgramme (wiring checked several times). I simply cannot connect to the motherboard:

Logfile (STM32CubeProgramme)
01:01:39 : UR connection mode is defined with the HWrst reset mode
01:01:39 : ST-LINK SN : 37FF71064E573…
01:01:39 : ST-LINK FW : V2J46S7
01:01:39 : Board : –
01:01:39 : Voltage : 3.23V
01:01:39 : Error: Unable to get core ID
01:01:39 : Error: Cannot connect to access port 0! If you are trying to connect to a device with TrustZone enabled, please try to connect with HotPlug mode. If you are trying to connect to a device that supports Debug Authentication with a certificate or password, please open your device using it.

As you can see, I’m going round in circles :frowning: Help.

//Ergänzung/Edit
If I disconnect all devices and try to list them (lsusb and /dev/serial/by-id/), the list is accordingly empty. So not even the motherboard or its Stm chip is recognised.

2026-01-31T00:00:00Z

2

@cardoc

3

This output is from the current OS via SSH?

Is the mainboard MCU

Is the OS actually compatible with the Sovol H616 SOM? I’ve never seen anyone successfully reimage a Sovol H616. The usual “hack” is run Klipper in a virtual machine.

You shouldn’t need STlink. The mainboard MCU is running Katapult bootloader and should accept firmware update VIA usb.

Do you have KIAUH installed?

4

Yes, that’s the output from the current OS over SSH.

It must definitely be the toolhead MCU, because it was the only device I was able to flash with Katapult using the ST-Link. I asked different AIs to help identify the devices and compared the results with my old printer.cfg entries from before the crash. The strongest evidence is that every other device on the mainboard disconnects. If nothing else is connected, the list is completely empty — the toolhead MCU does not appear at all.

The system had been running perfectly the whole time.

And yes, I have KIAUH installed. I use it for almost everything.

//edit: Grammar correction

5

image
image2101×904 77.8 KB

Your Mainboard MCU is right there

BUT Klipper firmware is not running.

Use Kiauh to “make and flash” for the STM32F103

6

I have documented all attempts thoroughly (thanks to AI!). I would still be interested to know how this could have happened, as I did not intervene in this MCU and only took action when the ‘crash’ suddenly occurred. :thinking:

============================================================
DIAGNOSTIC REPORT – MCU FAILURE ON THE SOVOL SV08 MAINBOARD
MCU Type: STM32F103 (Sovol SV08 Mainboard)
============================================================

1. INITIAL SITUATION
--------------------
The Debian system running on the printer does not detect any MCU serial
interface. The following device nodes are completely absent:

  /dev/ttyACM*
  /dev/ttyUSB*

This indicates that the STM32F103 MCU does not enumerate as a USB CDC
device. As a result, Klipper cannot start and KIAUH only reports
secondary errors.

--------------------------------------------------------
2. MEASUREMENT METHOD 1 – USB ENUMERATION ON THE PRINTER
--------------------------------------------------------
Command:
  ls /dev/ttyACM*
  ls /dev/ttyUSB*

Result:
  "No such file or directory"

Interpretation:
  - The MCU does not present itself over USB.
  - Neither the bootloader nor the firmware is active.
  - The USB transceiver or the MCU core is not functioning.

--------------------------------------------------------
3. MEASUREMENT METHOD 2 – ST-LINK / SWD CONNECTION
--------------------------------------------------------
Command:
  STM32_Programmer_CLI.exe -l
  STM32_Programmer_CLI.exe -c port=SWD

Result:
  - ST-Link is detected correctly.
  - Supply voltage of 3.25 V is measured.
  - Connection to the MCU fails:

    "Error: Unable to get core ID"
    "Error: Cannot connect to access port 0!"

Interpretation:
  - The MCU receives stable 3.3 V.
  - The SWD debug port does not respond.
  - The ST-Link cannot read the core ID or open the access port.
  - This is NOT typical for firmware or bootloader corruption.
  - This behavior only occurs when the STM32F103 is internally damaged.

--------------------------------------------------------
4. MEASUREMENT METHOD 3 – HOTPLUG / FORCED RESET (OPTIONAL)
--------------------------------------------------------
Typical additional tests:
  - Connecting in HotPlug mode
  - Connecting while holding NRST low (reset forced)

Expected behavior if the chip is alive:
  - At least a core ID is returned.

Expected behavior if the chip is defective:
  - Identical error messages as above.

Since the standard SWD connection already fails, success in these tests
is extremely unlikely.

--------------------------------------------------------
5. OVERALL ASSESSMENT
--------------------------------------------------------
All relevant communication paths to the MCU have failed:

  - No USB enumeration
  - No /dev/ttyACM0
  - No SWD access
  - No core ID
  - No access port
  - Supply voltage present

This is the characteristic failure pattern of an electrically damaged
STM32F103 microcontroller.

--------------------------------------------------------
6. PROBABLE CAUSE OF FAILURE
--------------------------------------------------------
Based on the measurements, the most likely defect is:

  → Internal hardware failure of the STM32F103
    (CPU core, SWD interface, or USB transceiver destroyed)

Possible triggers:
  - Toolhead short circuit
  - 24 V leakage into MCU-related lines
  - ESD damage via USB lines
  - Backfeed from a stepper driver
  - Overvoltage on the 3.3 V rail

--------------------------------------------------------
7. RECOMMENDED ACTION
--------------------------------------------------------
Since neither USB nor SWD responds, software recovery is impossible.
Only two options remain:

  A) Replace the STM32F103 (rework)
     – requires hot air, rework station, and experience

  B) Replace the entire mainboard
     – fastest and most reliable solution

I have documented all attempts thoroughly (thanks to AI!).

============================================================
END OF REPORT
============================================================
7

AI is wrong (shocking). Your STM32F103 is running katapult and only needs to be flashed with the correct communications settings, Once done it will create a serial over USB port and listen for klipper.

8

thanks you so much for your support. I really don’t understand what is happening. You tell me that is the mainboard. When that is the mainboard, where is my toolhead?

Do you have discord? I would show you that live if you want. I can share my screen.

2views

cardoc​

faggit

​

post by cardoc 4 mins ago

cardoc

4m

I prefer to work the problem on the forum. Might help other users. I’m excited you got the CM1 image flashed and running. First time I’ve seen that!

The STM32F402 is the toolhead

last visit

post by faggit 2 mins ago

faggit

2m

Are you sure? So I built a wrong firmware for the toolhead

The toolhead is happy ATM. Klipper runs the same firmware on all boards as long as the MCU, com configuration and BL offset are correct.

9

My thought is you forced the F402 firmware onto the F103 on the mainboard with the STlink. It can’t run that code so only the bootloader is active

10

I flashed Klipper now to the toolhead.
usb-Klipper_stm32f103xe_52FF6E067167485753191787-if00

I got the information from the official source: It is both stm32F103.
SV08/Motherboard/H616_JC_6Z_V1_2_MCU.pdf at main · Sovol3d/SV08 · GitHub
SV08/Motherboard/Extra_MCU.pdf at main · Sovol3d/SV08 · GitHub

Rappetor (Richard) · GitHub tells the same.

As I said I didn’t do anything to the motherboard before the crash.

Even if the wrong firmware was flashed, the ST‑Link should always be able to connect to the MCU. The debug interface (SWD) works independently of the bootloader and the flash contents. If the ST‑Link cannot read the core ID or open the access port, this points to a hardware‑level issue with the MCU itself, not a software or flashing mistake.

11

Unplug your toolhead and Eddy

run

What do you see?

12 
biqu@sovolsv08:~$ ls /dev/serial/by-id/
ls: cannot access '/dev/serial/by-id/': No such file or directory
13

Try a generic lsusb. if no plug a camera or memory stick in the back ant run again

14

Sorry for asking, it’s not my style to ask someone who’s helping me such a question, but have you read all of my posts?

NO USBDEVICES CONNECTED (for debugging):
biqu@sovolsv08:~$ lsusb
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+ STOCK WEBCAM:
biqu@sovolsv08:~$ lsusb
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 364d:6366 HHW microelectronics Co., Ltd. MGS1
Bus 003 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
biqu@sovolsv08:~$
+ TOOLHEAD
biqu@sovolsv08:~$ lsusb
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 364d:6366 HHW microelectronics Co., Ltd. MGS1
Bus 003 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 004: ID 1d50:614e OpenMoko, Inc. stm32f103xe
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
15

Okay I had them backwords.

Currently toolhead is stuck at bootloader (STM 34F103)
Main MCU is completely missing

when did you loose

The Klipper_stm32f042xxxx ?

16

meanwhile
usb-katapult_stm32f103xe_52FF6E067167485753191787-if00
is
usb-Klipper_stm32f103xe_52FF6E067167485753191787-if00
as is I said.

When all that happens idk. After eddy hardware installation (it is just an usb plug)…

17

Plug in everything but the eddy and use KIAUH to “find my MCU”

I think the mainboard MCU is “softbricked”. What is printed on the chip?

18

stm32f103vet6

Identifying MCU connected via USB ...
The following MCUs were found:
   ● MCU #0: /dev/serial/by-id/usb-Klipper_stm32f042x6_0F001400115330374E333320-if00
   ● MCU #1: /dev/serial/by-id/usb-Klipper_stm32f103xe_52FF6E067167485753191787-if00
╔═══════════════════════════════════════════════════════╗
║ Make sure that the controller board is connected now! ║
╟───────────────────────────────────────────────────────╢
║ How is the controller board connected to the host?    ║
╟───────────────────────────────────────────────────────╢
║ 1) USB                                                ║
║ 2) UART                                               ║
║ 3) USB (DFU mode)                                     ║
║ 4) USB (RP2040 mode)                                  ║
╟───────────────────────────┬───────────────────────────╢
║         B) « Back         │        H) Help [?]        ║
╚═══════════════════════════╧═══════════════════════════╝
###### Select connection type:
19

did you try choice 3? Can you locate a pad or pin labeled “boot0”?

20

yes, empty.

Neither a reset pin, an NRST pin nor a boot0 pin. And no additional pins for bridging either.