SKR 1.3 no USB device after update

Basic Information:

Printer Model: Custom
MCU / Printerboard: BTT Skr 1.3 (not pro, not turbo)

mcu 'mcu': Starting serial connect
34494 mcu 'mcu': Unable to open serial port: [Errno 2] could not open port /dev/serial/by-id/usb-Klipper_lpc1768_1B30011907083DAF17AC665CC62000F5-if00'

Describe your issue:

TL;DR: The USB device isn’t showing up after updating firmware to 0.12 on Skr 1.3.

I have been using v0.11 for a while and I updated to v0.12 today. I updated the pi software with kiauh and I used make menuconfig to build the firmware.bin.

This SKR has (as far as I remember) the original BTT firmware on it. These are the settings I used:

I believe these are the same settings I used originally when I compiled v0.11, but I don’t have any way to verify that.

I flashed the new firmware.bin using sdcard. The firmware.bin changed to FIRMWARE.CUR. I can also swap back, so I am pretty sure I am flashing the firmware correctly.

I have been watching dmesg and lsusb and the usb serial device doesn’t show up. I was seeing this error, but I don’t see anything in dmesg anymore:

  1 [  787.643326] usb 1-1.3: new full-speed USB device number 8 using xhci_hcd
  2 [  787.723535] usb 1-1.3: device descriptor read/64, error -32
  3 [  787.911597] usb 1-1.3: device descriptor read/64, error -32
  4 [  788.103291] usb 1-1.3: new full-speed USB device number 9 using xhci_hcd
  5 [  788.183546] usb 1-1.3: device descriptor read/64, error -32
  6 [  788.371586] usb 1-1.3: device descriptor read/64, error -32
  7 [  788.479921] usb 1-1-port3: attempt power cycle
  8 [  789.083307] usb 1-1.3: new full-speed USB device number 10 using xhci_hcd
  9 [  789.083591] usb 1-1.3: Device not responding to setup address.
 10 [  789.291557] usb 1-1.3: Device not responding to setup address.
 11 [  789.499311] usb 1-1.3: device not accepting address 10, error -71
 12 [  789.579379] usb 1-1.3: new full-speed USB device number 11 using xhci_hcd
 13 [  789.579662] usb 1-1.3: Device not responding to setup address.
 14 [  789.787543] usb 1-1.3: Device not responding to setup address.
 15 [  789.995351] usb 1-1.3: device not accepting address 11, error -71
 16 [  789.995962] usb 1-1-port3: unable to enumerate USB device

If I revert to the v0.11 firmware.bin, everything works. This is that working dmesg:

[ 1263.788783] usb 1-1.3: new full-speed USB device number 12 using xhci_hcd
[ 1263.898609] usb 1-1.3: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
[ 1263.898644] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1263.898658] usb 1-1.3: Product: lpc1768
[ 1263.898671] usb 1-1.3: Manufacturer: Klipper
[ 1263.898683] usb 1-1.3: SerialNumber: 1B30011907083DAF17AC665CC62000F5
[ 1263.968237] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device

I see in this post that @ReXT3D suggested a specific value in the GPIO output at boot section. But that is for the Katapult bootloader (which I’d like to use, after I get something stable with v0.12). Is there something I need to put in there for the skr 1.3?

Thank you in advance.

This seems strange.
I just tried on a SKR1.4T → works (from the firmware aspect, it should be pretty much the same). AFAIK nothing has changed for quite some time that might affect this.


make distclean
make menuconfig

Your settings appear to be correct and these boards do not require any startup pins.

1 Like

Thanks for responding. You were the other person I wanted to hear from, since you are on a lot of these skr threads.

I tried the distclean. The md5sum on klipper.bin is the same (16a627a9c18d8c85f65c8cfdf981323d) so I don’t think that changed anything.

Bummer. I was hoping that was it.

It definitely does. I would blame my hardware, but it still works on the v0.11. Maybe the next step is to try and check out the v0.11 version I was using and recreate that .bin. If that still works, then it must be something different in git. If I can’t get it to work, then I did some magic in Feb 2023, and I have no idea what.

Is there any other debugging I can do with the v0.12 version? I can see nothing shows up on dmesg. But should I try connecting over the serial/UART?

Do you agree that I shouldn’t try a new bootloader until I can figure this out?

It would definitively be interesting, if you can build a v0.11 version that works, since your dmesg is quite clearly showing that even the Linux OS is having hard time with the board.
Just for the fun of it, a klipper.bin compiled by me. Unfortunately, due to different underlying Linux OS you cannot compare the md5sum:

v0.12.0-125-gbfb71bc2 (22.6 KB)

If nothing else helps, I would try this as well. Maybe a messed bootloader. In any case, all my boards get katapult as it is way more convenient to update. See CanBoot: Flash BTT SKR 1.3 / 1.4 / 1.4 Turbo

OK. Strange again. Your klipper.bin works.

I’m on this commit:

pi@gridbot:~/klipper $ git log -n1
commit bfb71bc2dc63f2911a11ebf580f82b1e8b2706c4 (HEAD -> master, origin/master, origin/HEAD)
Date:   Fri Mar 15 22:12:05 2024 +0800

    stm32: Add i2c3_PC0_PC1 for stm32g0 (#6529)

    Signed-off-by: Alan.Ma from BigTreeTech <>

Truly strange. It is the same commit:

  • v0.12.0-125-gbfb71bc2
  • bfb71bc2 dc63f2911a11ebf580f82b1e8b2706c4

No idea, except a flash gone bad or something very weird in your Linux OS.

1 Like

ok. This was compiled on the raspberry pi. It’s running bullseye. I updated it using kiauh. Do you have a guess on which packages would affect it? Maybe binutils-arm?

binutils-arm-none-eabi/oldstable,now 2.35.2-2+14+b2 arm64 [installed]

Is there a docker container used to build the .bin that I can use? I have a Linux laptop, but I don’t like installing build tools on the host (to avoid conflicts).

I was able to create a working firmware.bin. I used the docker file in klipper:

docker build -f ./scripts/Dockerfile -t klipper . # from the top level klipper directory
docker run -it -t klipper /bin/bash
# Then I could run the make commands here.

I needed to install git-core to make the version string correct. But it’s working. So I no longer need to have Sineos build each version for me :slight_smile:.

This seems quite comforting for me :smiley:

But joking aside, I’d recommend to setup your Pi again. Get a recent Bookworm on the SD and use KIAUH to do the chore. Matter of 30 mins (make a backup of printer_data and put it back on the new setup).

I’d not trust a system that exhibits such behavior.

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