SKR 1.3 no USB device after update

General Discussion
1

Basic Information:

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

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:

Screenshot from 2024-03-17 13-06-21
Screenshot from 2024-03-17 13-06-21863×154 14.7 KB

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.

2

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.

Try:

make distclean
make menuconfig

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

1 Like
3

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?

4

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

5

OK. Strange again. Your klipper.bin works.

Screenshot from 2024-03-18 11-38-31
Screenshot from 2024-03-18 11-38-31725×275 25 KB

I’m on this commit:

pi@gridbot:~/klipper $ git log -n1
commit bfb71bc2dc63f2911a11ebf580f82b1e8b2706c4 (HEAD -> master, origin/master, origin/HEAD)
Author: BIGTREETECH <38851044+bigtreetech@users.noreply.github.com>
Date:   Fri Mar 15 22:12:05 2024 +0800

    stm32: Add i2c3_PC0_PC1 for stm32g0 (#6529)

    Signed-off-by: Alan.Ma from BigTreeTech <tech@biqu3d.com>
6

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
7

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).

8

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:.

9

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.

10

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