PI freezes after setting mcu USB id

Basic Information:

Printer Model: anycubic i3 mega
MCU / Printerboard: skr1.4t
Host / SBC: pi3b
klippy.log

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

hello everyone,
I have been trying to connect the skr1.4t by usb to my Klipper on the pi for some time now.
I have a skr on the printer, I loaded firmware by micro SD, the extension changed to .cur, so it got flashed. I can see see the USB id, I paste it in the printer.cfg from mainsail ( first tried fluidd ), and when I press reload…my pi freezes and I can only access it after power cycle.

Then I thought to make it simpler, and I used another skr1.4t that I had around. This one I flashed by USB TTL, just to be sure. I can see the mcu id in the device list and when I try to put the MCU id in the cfg file and reload…same thing happens: RPI freezes.

Any ideas?
I would like to keep the connection by usb so then I could maybe use the RPI screen also.

Thanks for reading, hope I was clear enough.

Hello @STK !

Any chance you can attach the klippy.log to your next post?

1 Like

hi. will attach it now. last night when i posted i had already disconnected the pi…and was in bed.
klippy (9).log (20.5 KB)

Hi! I have a similiar problem where my Pi (tried Pi 2 and a Pi 3B+ to rule out a hardware problem on the Pi) freezes (sometimes) as soon as klipper tries to connect to the MCU’s (SKR E3 V3 & Orbitool O2). Which also results in the Pi failing to boot randomly (works a few seconds until klipper trieds to connect the MCU’s and then it freezes.). It also happends sometimes if I power up the Pi first and the USB MCU’s afterwards. The Pi works until I power up the MCU’s and Klipper tries to connect, then it freezes (but not always, just sometimes).

for me it’s always. same on 2 boards ( both skr 1.4T )

Seems to be related to Kernels >6.1 because of USB current limitation or something in the USB stack:

USB current limitations start with kernel 6.5.5 · Issue #5623 · raspberrypi/linux

Kernel 6.5 freezes on boot on Pi 3 · Issue #5573 · raspberrypi/linux

But I can’t proof yet.

Solution seems to be either:

  • downgrade to Kernel 6.1
  • use powered USB hub
  • upgrade to kernel 6.7.

LE:
I have finally managed to get it working!
Don’t know if it is pure luck or not, but here it goes:

I worked on the board that was out of the printer, still sn SKR 1.4T, nothing on it ( not even drivers ).
Followed the flash sequence from here, with a USB TTL from btt. https://klipper.discourse.group/t/canboot-flash-btt-skr-1-3-1-4-1-4-turbo/3238
Then i used KIAUH and built and flashed from there directly to printer, the assitant identified the MCU id correctly.
After i put all my drivers in and connected the board to the printer and was able to control it.
Now i am tweaking the offsets and getting ready for the first print.
Thank you all for the support.

IMO, the topic of the Pi freezing and your shown process are not related.

Freezing the Pi probably means that it has crashed with a kernel panic or at least something very close to it.

Such severe errors are pretty much always due to:

  • Defective hardware (including wonky connectors, cables) either within the Pi itself or connected to it via its interfaces

  • Device firmwares that are connected to the RPi and are doing something really ugly and which is not properly handled on the Pi side

  • Driving the device out of specification, e.g., over-clocking, too low/high power/voltage supply, too high temperatures, etc.

  • Kernel or driver bugs

  • An unfortunate combination of the points above (the linked issue to the USB capabilities seems to be such an issue and would have been a good candidate for an explanation)

Overall, it can be stated that it is not so easy to drive a device into this state, and indeed something more serious (or unfortunate) has happened.

It really seems to be Kenrel related and starts to occur on Kernels > 6.1.
So downgrading to Kernel 6.1 seems to be the best solution:

rpi-update 5fc4f643d2e9c5aa972828705a902d184527ae3f

Another possible solution could be using dwc2 according to tis thread:

dwc_otg driver causing complete system freeze in stable 6.6.28 kernel (Home Assistant OS, RPi OS) · Issue #6172 · raspberrypi/linux

by adding dtoverlay=dwc2 to config.txt

I hope to find to some time this weekend for testing.

A post was split to a new topic: Issues when flashig MCU