MCU unable to connect BTT SKR Mini E3 V1.2

Basic Information:

Printer Model: Creality Ender 3 Pro 2020
MCU / Printerboard: BTT SKR Mini e3 V1.2
[klippy.log](https://pastebin.com/tNQZJ6w4)

Describe your issue:

Attempting to connect via USB to a desktop running Linux Mint 20.3. Reading similar topics have all pointed me to my firmware configuration being incorrect. I have double and triple checked it and flashed it 3 times. The board will not show when using “lsusb” or “ls /device/serial/by-id/”. I have tried several known working cables. The board used to connect when it was flashed with Marlin. Klipper config settings for firmware.

Might be this Solution: "MCU connection error" since at least April 30th due to Debian 11 update, but I’m not sure.

Good luck, hcet14

Thank you. I realize I left out I am trying to connect to a desktop running Linux Mint, perhaps this is relevant
This is my first foray into Linux and am thus a bit confused at most (all) times

I think this is you problem (klippy.log)
serial = /dev/serial/by-id/

That goes nowhere!

See Installation - Klipper documentation

Good luck, hcet14

post the output of sudo dmesg after disconnecting and reconnecting the board

the command “ls /dev/serial/by-id/" returns "ls: cannot access '/dev/serial/by-id/': No such file or directory”

searching for this error indicates my board’s firmware is not flashed correctly. So i have re-flashed it following documentation specific to the board a total of 3 times and it is still returning the same error; I’m not sure how I should continue. Thank you

here is the output.
Thank you

[92090.331769] usb 2-2: device descriptor read/64, error -32
[92090.439787] usb usb2-port2: attempt power cycle
[92090.439800] usb usb2-port2: failed to disable port power
[92090.567751] usb 2-2: new full-speed USB device number 83 using uhci_hcd
[92090.600089] usb 2-2: device descriptor read/8, error -32
[92090.735094] usb 2-2: device descriptor read/8, error -32
[92090.967754] usb 2-2: new full-speed USB device number 84 using uhci_hcd

This does not really look good.
Remove all other USB devices and try another USB port then post a new dmesg

Removed all other USB, changed to the port the mouse was using
new dmesg

Looks seriously f%&$. Whatever the reason is, your USB ports are massivly unhappy. Does the spamming of these erro messages stop when you disconnect the board?

You can do a live monitoring of dmesg with sudo dmesg -w

If it stops when disconnecting the board, then try a different USB cable as a start.

this is dmesg with no USB connected

do you have advice for making the ports happy? Could reinstalling the OS help or does this look like hardware issue?

thanks again

  • Was this output with the board disconnected?
  • There seem still additional USB devices connected, e.g. a webcam

that was the output with nothing plugged into the computer but power, ethernet, and monitor
no USB devices connected at all

[93672.138630] usb 1-2.4: USB disconnect, device number 97
[93672.139248] usb 1-2.4: cannot submit urb (err = -19)
[93681.104460] usb 1-2.4: new full-speed USB device number 98 using ehci-pci
[93681.213444] usb 1-2.4: New USB device found, idVendor=045e, idProduct=00f7, bcdDevice= 1.01
[93681.213449] usb 1-2.4: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[93681.213451] usb 1-2.4: Product: USB camera

Wonder where this is coming from then.

I have no idea what is messing up your USB ports, apparently not the printer board.
In any case, with this you will have no success.
You can try reinstalling Linux but if it is some strange hardware issue you will end up where you are.

There was previously a webcam plugged in. It’s definitely not now, but it is still showing up. Trying a restart of the desktop and will try dmesg again

I have restarted the host machine and dmesg now returns this

Looks way better now. Was the printer board connected?
If no, then please show the dmesg output directly after connecting the board.

Still to be noted that it seems like the USB keyboard got rest at least twice, so I’m not sure if this is a stable condition.

Yes, that dmesg is with the board connected):

At this point I’ve gotten it working. I reflashed the board again with firmware compiled directly from the host machine.
As of now I can access mainsail from the host machine but still can’t access it from my main computer, which is on the same network, after adding addresses to moonraker.conf

The connection with your network is lan or wifi?
If it is wifi you need to tell to your raspberry ssid and password.
make menuconfig and set your wifi id.
on ssh you need to take out your sd and add one text file named ssh with no extension or reflash sd with ssh option.