BigTreeTech SKR 3 EZ unable to connect klipper

Describe your issue:

Basic Information:

Printer Model: 100% custom (a kind of prusa mk3 bear)
MCU / Printerboard: BTT SKR 3 EZ
klippy.log: klippy.log (1.1 MB)


Following the difficulty with the lerdge-k card, I took a BTT SKR 3 EZ
I updated my BTT PAD7 as well as klipper, I put the correct options for the .bin, the card performs the flash as the .bin becomes a .CUR, klipper sees the processor to connect via USB , I changed the serial in printer.cfg, but still impossible to get klipper and the card to communicate…

I changed cards because the lerdge was blocking me from future developments, but here I’m really lost because when I see how to do the flash and everything goes “well” I don’t understand my mistake

If you have like me with the command “ls /dev/serial/by-id/*” the mcu of the card which is present but ending with an “-if” without anything extra like here on the pad7 :

biqu@BTT-Pad7:~$ ls /dev/serial/by-id/*

Or if the command does not work you can follow this tutorial which will repair the file to ensure that

=> ls: cannot access '/dev/serial/by-path': No such file or directory and ls: cannot access '/dev/usb-serial/by-id/': No such file or directory even after PR25246 applied · Issue #29201 · systemd/systemd · GitHub

it’s 4 commands to do.

  1. backup of “60-serial.rules”.
sudo mv /usr/lib/udev/rules.d/60-serial.rules /usr/lib/udev/rules.d/60-serial.rules.bak
  1. go to where the file is present.
cd /usr/lib/udev/rules.d/
  1. downloading the new file with the fix
sudo wget
  1. after the process is finished do this command to restart
sudo udevadm control --reload-rules && sudo udevadm trigger

and now the command “ls /dev/serial/by-id/*” should work normally

Try SSHing into the Klipper host and run:
sudo usermod -a -G dialout $USER

hello, I just did it but no change I just have this

Please show the output of following commands:

  • ls -al /dev/serial/by-id/usb-Klipper_stm32h723xx_170038000C51323433323831-if
  • ls /dev/serial/by-id/* (your serial seems to be not complete)
  • groups

Please as copy and paste and formatted as code and not as screenshots.

Hello, here is what it gives with the 3 commands :

biqu@BTT-Pad7:~$ ls -al /dev/serial/by-id/usb-Klipper_stm32h723xx_170038000C51323433323831-if
lrwxrwxrwx 1 root root 21 Apr 13 12:17 /dev/serial/by-id/usb-Klipper_stm32h723xx_170038000C51323433323831-if -> ../../bus/usb/002/005
biqu@BTT-Pad7:~$ ls /dev/serial/by-id/*
biqu@BTT-Pad7:~$ groups
biqu tty disk dialout sudo audio video plugdev games users systemd-journal input netdev ssh

$USER should have automatically replaced it with your username, don’t change the command, or use just “biqu”, not “$biqu”.

Haaaa I understand better xD, I just did it, now I have to flash again?

Hello, I have just re-tested using a basic printer.cfg, reverted to a lower version of klipper, but still nothing works, I placed the klippy and moonraker log in two githubs, I don’t know what search in both.

I’m not sure, what is happening here.
Klipper’s error message about “permission denied” could have been a group problem, as @Arakon initially correctly assumed. The output of the groups command is correct, though.

What looks strange is:


Usually, you will have two 00 at the like in the example above. Also

-> ../../bus/usb/002/005

does not look correct or at least I have never seen this.

I’d reflash the board, strictly following the information given here: SKR-3/Firmware/Klipper at master · bigtreetech/SKR-3 · GitHub

the big problem is that the processor they show is not the same as mine, on their printer.cfg file they say that there are two types and their .bin must not be So for the 743 I think I have the 723.

But I redid the procedure several times without any change, the only difference is (128KiB bootloader (SKR SE BX v2.0)) which I don’t have I just have (128KiB bootloader) but one person has it configured with no problem with that.

I will try to ask BTT the question to see if it is normal, I may have a defective product

What is your exact MCU type?

MCU type stm32h723

Hello, I just solved the problem by chance, after a test with a raspberry where everything was ok, I wanted to change the “60-serial.rules” file to have only the USB of the mcu connected instead of everything and by following a github I solved the problem…

If ever I share the link if necessary and I will add it at the top


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