Artillery Sidewinder X3 Pro: MCU enumerates over USB but never returns identify_response

General Discussion
1

Basic Information:

Printer Model: Artillery Sidewinder X3 Pro
MCU / Printerboard: STM32F402 (compiled as STM32F401), stock Artillery board
Host / SBC: Raspberry Pi 4B, MainsailOS 3.0.0, Klipper v0.13.0-642: attached

klippy.log (277.1 KB)

klippy.log

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

Converting from stock Marlin to Klipper. Flashed via SD card using the 48KiB bootloader path documented in printer-artillery-sidewinder-x3-plus-2024.cfg. Klipper never connects to the MCU:

mcu 'mcu': Unable to connect
Timeout on connect
Wait for identify_response

The board enumerates over USB reliably and the link stays up, but the identify handshake never completes.

What I’ve verified:

  • Flash completed — the bootloader renamed yuntu.bin to yuntu.CUR on the SD card
  • .config shows CONFIG_STM32_FLASH_START_C000=y (48KiB offset)
  • Board enumerates consistently as 1d50:614e, Manufacturer: Klipper, Product: stm32f401xc
  • dmesg -w shows zero disconnects during a failed connect attempt
  • Tried two USB ports on the Pi
  • fuser /dev/ttyACM0 returns nothing — no port contention
  • Exactly one klippy.py process running
  • ModemManager not installed on this image
  • With the Klipper service stopped, console.py also fails to identify despite exclusive port access
  • Tried restart_method: command and restart_method: arduino

Config is F1CU’s X3 Pro adaptation (F1CU/Artillery_Sidewinder_X3_Pro-Klipper) of TheFeralEngineer’s Plus config.

One uncertainty: I can’t confirm which firmware version my unit shipped with — I upgraded it at some point and the UI now reports V1.29. The flashing instructions branch on what the board shipped with (48KiB bootloader vs. no bootloader + DFU). Is there a way to determine which bootloader is actually present on the board, rather than inferring it from firmware history? The yuntu.CUR rename and the fact that the firmware executes both suggest a bootloader is present and the offset is right, but I’d like to confirm rather than assume.

Any suggestions for what else to check would be appreciated.

2

I agree that the file getting renamed in a good indication the bootloader is present and running.

I’d focus on com settings in the firmware build. Klipper firmware may be happily running on the MCU but looking at the wrong pins and never see the ID request.

Makes me think klipper firmware is installed… I’m not sure how the bootloader would detect Klipper firmware if the com was misconfigured.

Hopefully one of the more knowledgeable members will post soon.

3

Welcome hui1111,

did you follow Sineos Knowledge Base How-To Trouble-Shoot?