Sidewinder X4 Pro flash STM32F401xc

Basic Information:

Printer Model: Artillery Sidewinder X4 Pro
MCU / Printerboard: Artillery KL V1.01

Issue:

My mcu is no longer recognized on my Sidewinder X4 Pro. The following error appears on the display:

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

So I tried to solve the problem. I connected via ssh and entered lsusb. I get the following response:

mks@mkspi:~$ lsusb
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 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 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

What struck me was that the mcu was no longer listed. A few days ago there was another entry. I then opened the printer and pressed the RST button. The board restarts and the following is displayed under lsusb:

mks@mkspi:~$ lsusb
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 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 001 Device 002: ID 0483:df11 STMicroelectronics STM Device in DFU Mode
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

So I think the onboard connection works. I then tried to flash the firmware with various settings. These are the ones from my last attempt:

[ ] Enable extra low-level configuration options
    Micro-controller Architecture (STMicroelectronics STM32)  --->
    Processor model (STM32F401)  --->
    Bootloader offset (64KiB bootloader)  --->
    Communication interface (USB (on PA11/PA12))  --->

After the build went through, I tried to flash the firmware to the board using various commands:

make flash FLASH_DEVICE=0483:df11
----
sudo dfu-util -a 0 -i 0 -s 0x08000000:leave -D klipper.bin
----
sudo dfu-util -a 0 -D klipper.bin --dfuse-address 0x08000000:force:mass-erase:leave -d 0483:df11
----

All commands give me a success as feedback. After that, the mcu cannot be found under lsusb again. Only when I activate the DFU mode with the RST button.

I have also tried this, but still have no success: Web Programmer, “SecurityError: Access denied” on Linux (SOLVED) - Troubleshooting and Support - Daisy Forums (electro-smith.com)

Does anyone have any ideas what else I could do?

1 Like

Probably because it is yet another printer for which the sources are not made public and some unknown Klipper modification prevents you from using the original Klipper.

As with many others, like Elegoo, Anycubic etc, you are potentially stuck with the manufacturers’ firmware unless a developer is interested to port this to the Klipper mainline.

But why should it no longer work like that? It worked before and the problem only occurred after a few reboots. Before that, I managed to flash the firmware (flashed v12 - default from artillery v10) without any problems and was also able to print.
I have also checked the command history of the users and I do not see any adjustments from Artillery to Klipper. The printer has normal mks pi image with a customised .dtb file for the rk3328 so that WiFi works

Interesting, so you flash mainline Klipper before?

I do not know this board and apparently there are no instructions on how to build a proper firmware for this board.

Looking at the firmware file that Artillery is providing, then Klipper is definitively modified. To what extent is unknown and if it affects the firmware build is unknown as well.

Try flashing the original firmware and see if this works. If it does, then likely you have something wrong in your make menuconfig settings or even worse it is just not possible without access to the entire modified sources.

Yes, I had Klipper mainline v12 installed until it stopped working after 4-5 prints. After that, the mcu could no longer be found in lsusb and the error was there.

I have now tested a little more. I couldn’t flash the firmware from Artillery either. But what did work was katapult. I did the following:

H-RST button pressed on the board -> lsusb shows that it is in DFU mode
cd ~
git clone https://github.com/Arksine/CanBoot
pip3 install pyserial
cd CanBoot
make menuconfig
STM32F401 selected, rest default
make clean
make
sudo dfu-util -a 0 -D ~/CanBoot/out/canboot.bin --dfuse-address 0x08000000:force:mass-erase:leave -d 0483:df11

After that it was listed in lsusb again:
image

I then tried to install Klipper. This worked with the v10 from Artillery, with the v12 supposedly also, but there is no light on the extruder. Under ls /dev/serial/by-id/ it is listed as usb-Klipper_stm32f401xc_44001B000E51333037383638-if00, before the flash with klipper as usb-katapult_stm32f401xc_44001B000E51333037383638-if00. So it seems to have changed something. In Mainsail I now get a different error:

mcu 'rpi': 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

I then tried to fix the problem according to these instructions RPi microcontroller - Klipper documentation (Install the rc script + Building the micro-controller code), but did not notice any change. This is stored in the printer.cfg of the printer:

[mcu rpi]
serial: /tmp/klipper_host_mcu

If I run ls in /tmp, klipper_host_mcu is not listed. I think if this problem is fixed, the stm32 should also work properly now that it is finally displayed in lsusb again. But how can I fix the problem with the ‘rpi’ mcu?

Check Klipper-mcu Service Fails to Start

Thanks, that was easy and at least solved this error. I now get this error

But this is probably because spi is not working properly. When I enter ls /dev/spi* , I get ls: cannot access '/dev/spi*': No such file or directory

However, my /boot/armbianEnv.txt Config is set up with

overlays=spi-spidev
param_spidev_spi_bus=0

according to other posts on the Internet. If you have any ideas, please feel free to contact me again. Now that the problem only affects Armbian, I don’t think I’ll get any further here. I will have to debug it myself and find the reason. Thanks for the help :slight_smile:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.