Pressing the restart button is needed always

[dgrammatiko]

So I followed the instructions about getting a new firmware on the Pico, eg: on a plain board jumper on the usb-power, adding the boot number pressing the restart button then copying the file removing the boot number and then pressing the restart button.

The problem is that I always need to kill the Klipper service then press the restart button on the board and then restart the Klipper service

Use raspi-config to set the country before use.

pi@raspberrypi:~ $ ls /dev/serial/by-id/*
ls: cannot access '/dev/serial/by-id/*': No such file or directory
pi@raspberrypi:~ $ sudo service klipper stop
pi@raspberrypi:~ $ sudo service klipper stop
pi@raspberrypi:~ $ sudo service klipper stop
pi@raspberrypi:~ $ sudo service klipper start
pi@raspberrypi:~ $ ls /dev/serial/by-id/*
ls: cannot access '/dev/serial/by-id/*': No such file or directory
pi@raspberrypi:~ $ sudo service klipper stop
pi@raspberrypi:~ $ sudo service klipper start
pi@raspberrypi:~ $ ls /dev/serial/by-id/*
/dev/serial/by-id/usb-Klipper_rp2040_45503571280EB038-if00

I guess there's a bug in the boot loader

[Revilo91]

unfortunately i face the same issue, is there any help or bugfix for the future?

please reopen this issue

[bartlammers]

Exactly the same here, really annoying having to press the button on the board each time, hoping it will work.

[bartlammers]

@dgrammatiko did you get this fixed somehow? Seeing as you closed it initially?

[dgrammatiko]

@bartlammers no I switched back to my skr1.4 :(

[jlot2]

I'm also experiencing the same issue both when trying to do a firmware restart via console, host reboot, or a save and restart after editing the printer.cfg file. It reconnects normally maybe 1 out of 20 times (I'm in the middle of setting up my V0 for the first time so there's lots of firmware restarts).

Each time doesn't work, my klippy.log shows the following: mcu 'mcu': Starting serial connect mcu 'mcu': Unable to open serial port: [Errno 2] could not open port /dev/serial/by-id/usb-Klipper_rp2040_45503571278D5038-if00: [Errno 2] No such file or directory: '/dev/serial/by-id/usb-Klipper_rp2040_45503571278D5038-if00' webhooks client 1929910032: New connection webhooks client 1929910032: Client info {'program': 'Moonraker', 'version': 'v0.7.1-452-ga700725'} mcu 'mcu': Unable to open serial port: [Errno 2] could not open port /dev/serial/by-id/usb-Klipper_rp2040_45503571278D5038-if00: [Errno 2] No such file or directory: '/dev/serial/by-id/usb-Klipper_rp2040_45503571278D5038-if00' mcu 'mcu': Unable to open serial port: [Errno 2] could not open port /dev/serial/by-id/usb-Klipper_rp2040_45503571278D5038-if00: [Errno 2] No such file or directory: '/dev/serial/by-id/usb-Klipper_rp2040_45503571278D5038-if00' mcu 'mcu': Unable to open serial port: [Errno 2] could not open port /dev/serial/by-id/usb-Klipper_rp2040_45503571278D5038-if00: [Errno 2] No such file or directory: '/dev/serial/by-id/usb-Klipper_rp2040_45503571278D5038-if00' mcu 'mcu': Unable to open serial port: [Errno 2] could not open port /dev/serial/by-id/usb-Klipper_rp2040_45503571278D5038-if00: [Errno 2] No such file or directory: '/dev/serial/by-id/usb-Klipper_rp2040_45503571278D5038-if00'

I'm also connecting my Pi Zero 2W to the pico via USB. I wonder if this is issue affects only when connected via USB. I don't have GPIO pins soldered on my Pi yet, so I can't try to replicate it over UART yet.

[jakep82]

Same issue here. Board doesn't enumerate properly after bootup or a USB disconnect/reconnect. I've also tried UART and experience the same issue. After pressing the restart button on the board it connects properly and begins working, but this is a dealbreaker so I'll likely be requesting a return. Running Klipper Git version: v0.10.0-317-gb4b19b8f

After USB disconnect/reconnect

[  486.895871] usb 1-1.2: USB disconnect, device number 15
[  488.317369] usb 1-1.2: new full-speed USB device number 16 using dwc_otg
[  488.527389] usb 1-1.2: device descriptor read/64, error -32
[  488.847366] usb 1-1.2: device descriptor read/64, error -32
[  489.177381] usb 1-1.2: new full-speed USB device number 17 using dwc_otg
[  489.377368] usb 1-1.2: device descriptor read/64, error -32
[  489.697409] usb 1-1.2: device descriptor read/64, error -32
[  489.817473] usb 1-1-port2: attempt power cycle
[  490.577355] usb 1-1.2: new full-speed USB device number 18 using dwc_otg
[  491.017387] usb 1-1.2: device not accepting address 18, error -32
[  491.217424] usb 1-1.2: new full-speed USB device number 19 using dwc_otg
[  491.657397] usb 1-1.2: device not accepting address 19, error -32
[  491.657547] usb 1-1-port2: unable to enumerate USB device

After pressing reset button

[  494.717429] usb 1-1.2: new full-speed USB device number 20 using dwc_otg
[  494.951673] usb 1-1.2: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
[  494.951699] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  494.951714] usb 1-1.2: Product: rp2040
[  494.951729] usb 1-1.2: Manufacturer: Klipper
[  494.951744] usb 1-1.2: SerialNumber: 455035712814D208
[  494.953083] cdc_acm 1-1.2:1.0: ttyACM1: USB ACM device

[jlot2]

@jakep82 I've since added the GPIO header to my Pi Zero 2 W and I'm definitely seeing this happen less, but it still happens occasionally. It's maybe 1 out of 10 times, but it's better than it happening 9 out of 10 times like it was over USB-C. I think it's usually when I make an update to my printer.cfg and do a "Save and Restart".

I have the back cover on my Voron V0.1, so I can't easily access the reset button on the Pico, so I've always just cycled the main power switch on the printer.

[jakep82]

@jlot2 This doesn't work for me. The board won't connect after initial boot regardless of whether it's connected via USB or UART. I've fully updated my system and reflashed the board after a make distclean, but still no dice. It will only connect after pressing the reset button.

[bartlammers]

I contacted someone from BTT about this and they suggested it has to do with the power supply. No luck changing them up for me, but maybe it can help someone else?

[bartlammers]

To add, I tried with a different Pi (4) instead of my Zero2, to no effect. Also going to UART had no improvement. Starting in bootloader mode does work well btw, so could it be a bootloader issue?

[jakep82]

@bartlammers Are you saying it works if you leave the boot jumper on the board? That's probably the only thing I haven't tried, but I would be surprised if the board operated correctly with the jumper in place.

[bartlammers]

@bartlammers Are you saying it works if you leave the boot jumper on the board? That's probably the only thing I haven't tried, but I would be surprised if the board operated correctly with the jumper in place.

Indeed, but that does mean you are in bootloader mode and won't be able to run it, just flash

[NAPCAL]

Note: I am using the Raspberry Pi Pico official, not running into this issue via USB communications. Klipper shows v0.10.0-323-g80492432

[mitofun]

yep have the same issue in order to start the klipper need to press the reset button on the skr pico also the gcode for leds does not work!((((

[mitofun]

Note: I am using the Raspberry Pi Pico official, not running into this issue via USB communications. Klipper shows v0.10.0-323-g80492432

i consider the skr pico as the compact and small boars- once you use the usb it is not so compact so far! also the connection pins are not so confirtable for use! beter to solder it from the back and the cables position down instead of the sides! also very useful would be the thermosensors on tms drivers! and a fan switching on automaticall ) the radiator is uselss as it have not any use to get the temperature off the drivers!

[bartlammers]

Just installed a new SKR Pico that I ordered to test and with this one it works just fine it seems (did about 10 cold starts now, completely powering off in the meantime). Is there something changed compared to the first batch perhaps?

[mitofun]

mine dated 2022-3-14

[fraserws]

Any updates on this, mine is only working like 1 out of 10 times while changing nothing.

[fraserws]

Just to clarify, for me to temporarily solve this issue I must; restart the firmware via mainsail and press the reset button during the restart process, after which the green led comes on and the connection succeeds.

[mitofun]

The Btt sending the new board to me - regarding the issue the Btt subject me to do this one To sure cut these two pins but nothing works !

[mitofun]

[mitofun]

[mitofun]

Just to clarify, for me to temporarily solve this issue I must; restart the firmware via mainsail and press the reset button during the restart process, after which the green led comes on and the connection succeeds. Will it start suscessfully after power recycle ?

[fraserws]

Ok, I seemed to have resolved this. The problem seemed to be the fact that i was adding unnecessary arguments in the boot config file as mainsailos was already reconfigured to work.

So if anyone is facing the same issue as me I recommend a clean install of mainsail and then to flash the board as usual and then adding the appropriate printer.cfg file to the pi.

Hope this helps.

[bartlammers]

Ok, I seemed to have resolved this. The problem seemed to be the fact that i was adding unnecessary arguments in the boot config file as mainsailos was already reconfigured to work.

So if anyone is facing the same issue as me I recommend a clean install of mainsail and then to flash the board as usual and then adding the appropriate printer.cfg file to the pi.

Hope this helps.

Weird then, how swapping the board for a new one solved the issues for me, not changing anything else on the Pi. Literally flashed the same compiled firmware to both boards.

[mitofun]

Ok, I seemed to have resolved this. The problem seemed to be the fact that i was adding unnecessary arguments in the boot config file as mainsailos was already reconfigured to work.

So if anyone is facing the same issue as me I recommend a clean install of mainsail and then to flash the board as usual and then adding the appropriate printer.cfg file to the pi.

Hope this helps.

Does not help in my case - waiting for a new board

[boverby]

my setup has same problem. It tested without any obvious problems until last week when OS, klipper and moonraker were updated [apply forehead to desk].

These are the results of trying to revert klipper / FW back to dec 13 to match original firmware from skr pico GitHub page,

cd /home/pi/klipper
git reset 323268ea02700b2fd3b6accda310845ba29c894e

kiauh reports klipper now at v0.10.0-180 build firmware using kiauh

install jumper, reset

Jun 14 10:06:57 p6 kernel: [ 2055.249940] usb 1-1.4: USB disconnect, device number 9
Jun 14 10:06:57 p6 kernel: [ 2055.554286] usb 1-1.4: new full-speed USB device number 10 using dwc_otg
Jun 14 10:06:57 p6 kernel: [ 2055.686909] usb 1-1.4: New USB device found, idVendor=2e8a, idProduct=0003, bcdDevice= 1.00
Jun 14 10:06:57 p6 kernel: [ 2055.686928] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun 14 10:06:57 p6 kernel: [ 2055.686942] usb 1-1.4: Product: RP2 Boot
Jun 14 10:06:57 p6 kernel: [ 2055.686955] usb 1-1.4: Manufacturer: Raspberry Pi
Jun 14 10:06:57 p6 kernel: [ 2055.686967] usb 1-1.4: SerialNumber: E0C9125B0D9B
Jun 14 10:06:57 p6 kernel: [ 2055.687987] usb-storage 1-1.4:1.0: USB Mass Storage device detected
Jun 14 10:06:57 p6 kernel: [ 2055.688665] scsi host0: usb-storage 1-1.4:1.0
Jun 14 10:06:57 p6 mtp-probe: checking bus 1, device 10: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4"
Jun 14 10:06:57 p6 mtp-probe: bus: 1, device: 10 was not an MTP device
Jun 14 10:06:57 p6 kernel: [ 2055.751178] usbcore: registered new interface driver uas
Jun 14 10:06:57 p6 mtp-probe: checking bus 1, device 10: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4"
Jun 14 10:06:57 p6 mtp-probe: bus: 1, device: 10 was not an MTP device
Jun 14 10:06:58 p6 kernel: [ 2056.725520] scsi 0:0:0:0: Direct-Access     RPI      RP2              3    PQ: 0 ANSI: 2
Jun 14 10:06:58 p6 kernel: [ 2056.732852] sd 0:0:0:0: [sda] 262144 512-byte logical blocks: (134 MB/128 MiB)
Jun 14 10:06:58 p6 kernel: [ 2056.734307] sd 0:0:0:0: [sda] Write Protect is off
Jun 14 10:06:58 p6 kernel: [ 2056.754412] sd 0:0:0:0: Attached scsi generic sg0 type 0
Jun 14 10:06:58 p6 kernel: [ 2056.797987]  sda: sda1
Jun 14 10:06:58 p6 kernel: [ 2056.803892] sd 0:0:0:0: [sda] Attached SCSI removable disk

[ check of /proc/partitions show pico mounted as partition /dev/sda1 on my machine]

root@p6:/mnt# mkdir -p /mnt/sda1
root@p6:/mnt# mount /dev/sda1 /mnt/sda1
root@p6:/mnt# ls /mnt/sda1
INDEX.HTM  INFO_UF2.TXT

root@p6:/mnt# cp /home/pi/klipper/out/klipper.uf2 /mnt/sda1

first test remove jumper, reset pico

Jun 14 10:09:00 p6 kernel: [ 2177.873961] usb 1-1.4: USB disconnect, device number 10
Jun 14 10:09:00 p6 kernel: [ 2178.394753] usb 1-1.4: new full-speed USB device number 11 using dwc_otg
Jun 14 10:09:00 p6 kernel: [ 2178.529548] usb 1-1.4: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
Jun 14 10:09:00 p6 kernel: [ 2178.529576] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun 14 10:09:00 p6 kernel: [ 2178.529608] usb 1-1.4: Product: rp2040
Jun 14 10:09:00 p6 kernel: [ 2178.529623] usb 1-1.4: Manufacturer: Klipper
Jun 14 10:09:00 p6 kernel: [ 2178.529637] usb 1-1.4: SerialNumber: 45503571270BC008
Jun 14 10:09:00 p6 kernel: [ 2178.530945] cdc_acm 1-1.4:1.0: ttyACM1: USB ACM device
Jun 14 10:09:00 p6 mtp-probe: checking bus 1, device 11: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4"
Jun 14 10:09:00 p6 mtp-probe: bus: 1, device: 11 was not an MTP device
Jun 14 10:09:00 p6 mtp-probe: checking bus 1, device 11: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4"
Jun 14 10:09:00 p6 mtp-probe: bus: 1, device: 11 was not an MTP device

root@p6:~# ls /dev/serial/by-id
usb-Klipper_rp2040_45503571270BC008-if00

firmware restart -- works

second test: reboot pi host , pico still powered no device created reset required to reconnect

third test

power down pico (klipper will notice lost mcu)
reboot pi host
after host goes login, check fluidd page
   should report "unknown"
   klipper.log reports unable to open serial port
power up pico
   serial port is found and fluidd shows happy machine

This looks like the sensitivity to power up sequence means something has changed in the mcu resetting flowchart/command on klipper side

ps results same for

v0.10.0-180-g323268ea-dirty-20220614_100528-p6   ( my build from december git)
v0.10.0-181-ge9c37688   (github download)
v0.10.0-462-gea4f6d6a  (build from most current)

[boverby]

continued discovery. Tried another raspberry pi 3 with older OS [buster] and never had klipper installed.

these lines are captured from journalctl: same result. I do not think it is on the pi side...

Jun 20 11:45:07 taz kernel: usb 1-1.3: new full-speed USB device number 4 using dwc_otg
...
Jun 20 11:45:07 taz kernel: usb 1-1.3: device descriptor read/64, error -32
Jun 20 11:45:07 taz kernel: usb 1-1.3: device descriptor read/64, error -32
Jun 20 11:45:07 taz kernel: usb 1-1.3: new full-speed USB device number 5 using dwc_otg
Jun 20 11:45:07 taz kernel: usb 1-1.3: device descriptor read/64, error -32
Jun 20 11:45:07 taz kernel: usb 1-1.3: device descriptor read/64, error -32
Jun 20 11:45:07 taz kernel: usb 1-1-port3: attempt power cycle
...
Jun 20 11:45:07 taz kernel: usb 1-1.3: new full-speed USB device number 7 using dwc_otg
...
Jun 20 11:45:08 taz kernel: usb 1-1.3: device not accepting address 7, error -32
Jun 20 11:45:08 taz kernel: usb 1-1-port3: unable to enumerate USB device

[press reset button on pico]

Jun 20 11:59:23 taz kernel: usb 1-1.3: new full-speed USB device number 8 using dwc_otg
Jun 20 11:59:23 taz kernel: usb 1-1.3: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
Jun 20 11:59:23 taz kernel: usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun 20 11:59:23 taz kernel: usb 1-1.3: Product: rp2040
Jun 20 11:59:23 taz kernel: usb 1-1.3: Manufacturer: Klipper
Jun 20 11:59:23 taz kernel: usb 1-1.3: SerialNumber: 45503571270BC008
Jun 20 11:59:23 taz mtp-probe[1449]: checking bus 1, device 8: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3"
Jun 20 11:59:23 taz mtp-probe[1449]: bus: 1, device: 8 was not an MTP device
Jun 20 11:59:23 taz kernel: cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
Jun 20 11:59:23 taz kernel: usbcore: registered new interface driver cdc_acm
Jun 20 11:59:23 taz kernel: cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
Jun 20 11:59:23 taz mtp-probe[1453]: checking bus 1, device 8: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3"
Jun 20 11:59:23 taz mtp-probe[1453]: bus: 1, device: 8 was not an MTP device

more discovery: removed or commented out restart lines in [mcu] stanza. Now the board requires reset on power-up, but successfully finds serial port after additional klipper or firmware restarts. I suspect this because the pico is NOT restarted. (good news/bad news)

[mcu]
serial: /dev/serial/by-id/usb-Klipper_rp2040_45503571270BC008-if00
###restart_method: command   ### from github config
###restart_method: rpi_usb       ### earlier attempt to get usb to reset , did not work

[mitofun]

this is due to the mcu loading boot - so the btt have send to me the new board! the old one will be for testings(((

[tonyshackelton]

I have not had this issue occur at all. I was using USB, then moved to UART, no problems... I don't think it's the board (I'm not aware of multiple revisions). I am using PIOS bullseye and kiahu for whatever that's worth. I did have a bad fuse that was getting crazy hot until I clicked it back together and reseated it, so you may want to look into power. I could see flakey power making the MCU restart few times (think non-debounced button) and really making it angry. I assume everyone is powering the pi via the pico, if not start there.

[waggawaggawagga]

I am having the same issue on my SKR Mini E3 v2. Randomly decides to lose its connection to my Pi 3B+ with "device descriptor read/64, error -32". BTT hardware problem?

[boverby]

Wagga1: In my case I have not run it long enough to see if it randomly loses. I am hung up on a successful power up start.

in any case, see if your /var/log/messages file on raspberry pi looks similar to this

during power up boot: ( use command "dmesg | grep usb")

note: your usb enumerators may be different

[    4.434471] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[    4.534414] usb 1-1.2: device descriptor read/64, error -32
[    4.764433] usb 1-1.2: device descriptor read/64, error -32
[    4.984378] usb 1-1.2: new full-speed USB device number 5 using dwc_otg
[    5.084407] usb 1-1.2: device descriptor read/64, error -32
[    5.304374] usb 1-1.2: device descriptor read/64, error -32
[    5.424652] usb 1-1-port2: attempt power cycle
[    6.084428] usb 1-1.2: new full-speed USB device number 6 using dwc_otg
[    6.524411] usb 1-1.2: device not accepting address 6, error -32
[    6.624476] usb 1-1.2: new full-speed USB device number 7 using dwc_otg
[    7.074427] usb 1-1.2: device not accepting address 7, error -32
[    7.074682] usb 1-1-port2: unable to enumerate USB device

and after hitting reset button:

un 26 07:43:19 p6 kernel: [  479.052206] usb 1-1.2: USB disconnect, device number 12
Jun 26 07:43:19 p6 kernel: [  479.350519] usb 1-1.2: new full-speed USB device number 13 using dwc_otg
Jun 26 07:43:19 p6 kernel: [  479.484813] usb 1-1.2: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
Jun 26 07:43:19 p6 kernel: [  479.484836] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun 26 07:43:19 p6 kernel: [  479.484849] usb 1-1.2: Product: rp2040
Jun 26 07:43:19 p6 kernel: [  479.484862] usb 1-1.2: Manufacturer: Klipper
Jun 26 07:43:19 p6 kernel: [  479.484874] usb 1-1.2: SerialNumber: 45503571270BC008
Jun 26 07:43:19 p6 kernel: [  479.486023] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
Jun 26 07:43:19 p6 mtp-probe: checking bus 1, device 13: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2"
Jun 26 07:43:19 p6 mtp-probe: bus: 1, device: 13 was not an MTP device
Jun 26 07:43:19 p6 mtp-probe: checking bus 1, device 13: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2"
Jun 26 07:43:19 p6 mtp-probe: bus: 1, device: 13 was not an MTP device

After the initial manual reset, I can get the board to FIRMWARE_RESTART or RESTART_KLIPPER via fluidd

I have dug up a reference; https://askubuntu.com/questions/341241/ubuntu-wont-start-with-device-descriptor-read-64-error-32-what-does-this-m

This asserts that the problem is "over-current", the solution is to unplug usb wait a minute and re-insert. This might be it, but I tried using a powered usb hub between rpi and pico - no difference. I also checked usb voltage and it stayed within tolerances ( 5v).

getting ready to try a non-raspi klipper host to rule that out.

[socks415]

I’ve been experiencing the same issue with my skr 2 and rpi4. I also tried different usb cords and a different rpi. I have to unplug, wait 5-10 seconds and plug back in the usb for it to interface anytime the firmware is reset. It’s so annoying.

[sffrankie]

continued discovery. Tried another raspberry pi 3 with older OS [buster] and never had klipper installed.

these lines are captured from journalctl: same result. I do not think it is on the pi side...

Jun 20 11:45:07 taz kernel: usb 1-1.3: new full-speed USB device number 4 using dwc_otg
...
Jun 20 11:45:07 taz kernel: usb 1-1.3: device descriptor read/64, error -32
Jun 20 11:45:07 taz kernel: usb 1-1.3: device descriptor read/64, error -32
Jun 20 11:45:07 taz kernel: usb 1-1.3: new full-speed USB device number 5 using dwc_otg
Jun 20 11:45:07 taz kernel: usb 1-1.3: device descriptor read/64, error -32
Jun 20 11:45:07 taz kernel: usb 1-1.3: device descriptor read/64, error -32
Jun 20 11:45:07 taz kernel: usb 1-1-port3: attempt power cycle
...
Jun 20 11:45:07 taz kernel: usb 1-1.3: new full-speed USB device number 7 using dwc_otg
...
Jun 20 11:45:08 taz kernel: usb 1-1.3: device not accepting address 7, error -32
Jun 20 11:45:08 taz kernel: usb 1-1-port3: unable to enumerate USB device

[press reset button on pico]

Jun 20 11:59:23 taz kernel: usb 1-1.3: new full-speed USB device number 8 using dwc_otg
Jun 20 11:59:23 taz kernel: usb 1-1.3: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
Jun 20 11:59:23 taz kernel: usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun 20 11:59:23 taz kernel: usb 1-1.3: Product: rp2040
Jun 20 11:59:23 taz kernel: usb 1-1.3: Manufacturer: Klipper
Jun 20 11:59:23 taz kernel: usb 1-1.3: SerialNumber: 45503571270BC008
Jun 20 11:59:23 taz mtp-probe[1449]: checking bus 1, device 8: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3"
Jun 20 11:59:23 taz mtp-probe[1449]: bus: 1, device: 8 was not an MTP device
Jun 20 11:59:23 taz kernel: cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
Jun 20 11:59:23 taz kernel: usbcore: registered new interface driver cdc_acm
Jun 20 11:59:23 taz kernel: cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
Jun 20 11:59:23 taz mtp-probe[1453]: checking bus 1, device 8: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3"
Jun 20 11:59:23 taz mtp-probe[1453]: bus: 1, device: 8 was not an MTP device

more discovery: removed or commented out restart lines in [mcu] stanza. Now the board requires reset on power-up, but successfully finds serial port after additional klipper or firmware restarts. I suspect this because the pico is NOT restarted. (good news/bad news)

[mcu]
serial: /dev/serial/by-id/usb-Klipper_rp2040_45503571270BC008-if00
###restart_method: command   ### from github config
###restart_method: rpi_usb       ### earlier attempt to get usb to reset , did not work

I was having that same issue on my skr mini v3 and thought that I must have damaged the USB port moving my printer around. I only popped in here because I’ve got a pico set to arrive for another printer and wanted to see what to look out for ahead of time.

What ended up fixing my skr mini was wiping my pi (which I needed to anyway)and starting fresh and switching to UART.

[NAPCAL]

I added a Zero4U - 4 Port USB Hub for Raspberry Pi Zero v1.3 to my RPi Zero 2W; this device indicates when a USB device is connected. I noticed after some time that the RPi RP2040 (Pico) would drop the USB connection even if it were plugged in, the RPi Pico doesn't have a reset button, and the only way was to unplug the USB cable and plug it back in to bring it back on-line.

Maybe there is a sleep or low power mode the RP2040 that is on the BTT Pico & RPi Pico is dropping into, and a reset or power cycle (unplugging, plug back in) will bring it out if it.

I just wanted to provide an observation.

[vkhodygo]

@boverby

getting ready to try a non-raspi klipper host to rule that out.

I experience a similar (the same?) problem while running Klipper on a vbox machine. Mind you, USB forwarding worked just fine with my other non-BTT board, however, now my USB connection fails every time I start the guest system. I can reset the board, but it makes no difference while the virtual machine is running.

[apollo-mg]

Same problem with Pi Zero 2 W connected to the SKR Pico over GPIO.

[boanerges57]

To add, I tried with a different Pi (4) instead of my Zero2, to no effect. Also going to UART had no improvement. Starting in bootloader mode does work well btw, so could it be a bootloader issue?

I looked and saw my RPi was reporting TWO connected MCUs and neither was on serial0

[MCU] serial: /dev/ttyS0 serial: /dev/ttyAMA0

solved my issue. I am now connected and have the green light, no more issues - I also have the control method set to command.

EDIT- nevermind, I have issues. I tried a nanopi neo and it only reports one MCU. But I'm having trouble getting it to connect to it. The Rpi worked until I powered it down, now it needs resets to connect. Printing is going well, getting everything tuned and set up properly is my biggest current challenge. I'm still trying to get the NanoPi to work and I'm resigned to trying to convince btt tech support that it shouldn't work this way.

[boanerges57]

PuTTY into your Pi, Run kiauh advanced in the menu for burning firmware it has the option to identify MCUs In mine it saw two When I added BOTH into my [MCU] in printer.cfg it finally all worked, adding one or the other didnt help. I am connected via UART. This may still be useful for USB, there is no reason USB couldn't decide to be two MCUs.

In Klipper it still all works as a single MCU though.

[fraserws]

would you be able to share your exact cfg for the mcu section, I tried putting mine as:

[mcu] serial: /dev/ttyAMA0 serial: /dev/ttyS0 restart_method: command

but doesn't work

[boanerges57]

would you be able to share your exact cfg for the mcu section, I tried putting mine as:

[mcu] serial: /dev/ttyAMA0 serial: /dev/ttyS0 restart_method: command

but doesn't work

Does that correspond to what kiauh showed you? Try adding serial: /dev/serial0

That what I initially did (purely out of frustration) and it worked. I had them all typed in but commented out whatever I wasn't using. I uncommented all of them and my light came on. Then I remembered that two mcus kept showing up in kiauh.

I also still have to make sure my RPi boots first before I power up the pico. I'm also kind of wondering if this isn't the pico but the pi. I feel like there is an issue with using the RPi imager to create the sd card. I'm going to try an install from scratch. I saw a bunch of errors in the OS logs that related to missing python stuff. Otherwise I might need to put a delay on things. I'm not terribly happy with having to power the pi separately.

I've got a nanopi neo arriving tomorrow. I'll be setting that up purely with kiauh.

Edit: also that is exactly how my [MCU] section is right now.

[boanerges57]

Currently my config is

[MCU] serial: /dev/ttyS0 serial: /dev/ttyAMA0 serial: /dev/serial0 restart_method: command

However - It doesn't seem to be restarting properly unless I press the button. It does connect and it does print. I might try it on USB. Currently it is being powered separately from the pi. I might try running it from another power supply I have. I have a relatively high quality 12V supply. I might check my 24V supply for noise/output stability but from what I can tell it is a reasonably good supply and I know it is capable of the full 15A output, but I haven't checked how stable the output is. It looks like there are enough capacitors to keep it fairly stable. If not I think I have enough hardware to build a reasonably stable output 24V 20A psu and I think I have the right parts to stick a pi on it to measure voltage and current fluctuations. It would be simpler if I just had the spare $$ for an oscilloscope.

[boanerges57]

I was going to post a video of my printer running on the pico. It's basically an ender 3 clone that came with some upgrades already fitted. But now it may as well just be an ender 3 frame and bed that has a biqu h2 extruder/hot end, a 3d touch (knock off BL touch), and the SKR Pico/RPi 3b combo.

At least it is connecting, I wish the reset issue wasn't still here (it is very sensitive to the timing of when the pico is powered up vs the RPi. I still think it is an issue in the RPi causing this. I'm going to try my RPi 4 and Zero W to see if they have this issue and I will also try USB. I have an Intel atom miniPC I might try too.

If anyone has specific info they want let me know what it is and how to pull that data if you know. I will try to grab it, I'm not good at Linux/debian, I learned Unix/Linux a long time ago and forgot a lot of it (TBI sucks).

[GadgetAngel]

I am implementing the TinyFAN PCB (https://github.com/Gi7mo/TinyFan) on my Voron 2.4 build to control PWM fans for my Voron build. I have the Octopus Pro on USB-A to the Raspberry Pi 4B and the TinyFAN's RP2040-zero on port two of the USB-A of the Raspberry Pi 4B.

My TinyFAN PCB's RP2040-zero is the same processor as the one found on the BTT SKR Pico.

The instability of the USB connection from the RP2040 device to the Raspberry Pi is due to the RP2040. See https://github.com/Klipper3d/klipper/pull/4748#issue-1013362088 : I quote: “RP2040 datasheet better explains the issue, but in a nutshell the USB controller requires800us of J-state(D+ high, D- low) to transition from RESET to CONNECTED. On a busy USB bus, e.g. on a single-TT hub with other 12Mbps USB devices, this might never happen”.

Here are two work-a-rounds to this problem:

1. add a remote physical "RESET" button to the Skirt on the Voron 2.4 build
2. install "uhubctl" on the Pi to power off and them power on the USB-A ports (basically to "RESET" the RP2040 usb-c por which is really a USB-A port on the Pi)

To do #1 work-a-round a couple of items are needed:

1. wire
2. Skirt mount for a 16mm button :
3. https://github.com/hartk1213/MISC/blob/main/Voron%20Mods/Voron%202/2.4/Voron2.4_16mm_button_skirt/STLs/16mm_button_skirt_insert_front.stl
4. I had to trim the "16mm_button_skirt_insert_front.stl" piece down with my Dremel tool so that I could use the retaining "screw on" collar that came with the 16mm momentary button I bought off of Amazon
5. buy a 16mm momentary button from of Amazon at https://www.amazon.com/dp/B01MQV6NJR
6. Hot Glue Gun and Hot Glue to secure the 16mm momentary button from of Amazon mounted on to "16mm_button_skirt_insert_front.stl" piece with the provided screw on collar. The screw on collar will secure the button to the "16mm_button_skirt_insert_front.stl" piece but not to the skirt. So use some hot glue to ensure the "16mm_button_skirt_insert_front.stl" piece stays on the Skirt. I placed hot glue on the backside of the Skirt.
7. one "Short USB-A to USB-C" cable : https://www.amazon.com/gp/product/B08933P982
8. cut the "Short USB-A to USB-C" cable so that you can wire the 16mm button in between the cut pieces.
9. There are 4 wires inside the "Short USB-A to USB-C" cable. Strip the cut ends to gain access to the wires. There is a BLACK (GND), RED (5V), GREEN (Data+) and White (Data-) wires inside. Follow the below diagram on how to hookup the switch between the two halves of the short USB-A to USB-C cable.

To do #2 work-a-round a couple of items are needed:

1. see, https://klipper.discourse.group/t/rp2040-pico-suddenly-unable-to-connect-usb-issue/2554
2. see https://funprojects.blog/2021/04/26/control-usb-powered-devices/
3. To install uhubctl:

      $sudo apt-get install libusb-1.0-0-dev
      $git clone https://github.com/mvp/uhubctl
      $cd uhubctl
      $make
      $sudo make install

Edit: 10/16/2022 I just tried using uhubctl to power off and power on the USB port for the RP2040.

As you can see from the above picture, my RP2040 is on port 4 of 1-1 USB hub:

$sudo uhubctl -l 1-1 -p 4 -a off
$sudo uhubctl -l 1-1 -p 4 -a on

But when I try to cycle the power on the port 4, the power will be turn off and then on again but the RP2040 will not go through the USB enumeration process again. All I get is the power is on but the USB-ID is not shown:

But if I hit the 'physical "RESET"' button I installed the RP2040, will now display a USB-ID:

Conclusion: the only work-around to this is to just install a physical "RESET" button that interrupts the 5V line going to the USB-C of the RP2040 board! Unfortunately, every time you power up your printer you will need to hit this physical "RESET" button to get the RP2040 USB-ID to appear to the Raspberry Pi.

My next idea is to attach a Digital Relay to the button to see if I can remotely control this action via software. I will update if I can get this accomplished.

[GadgetAngel]

For the RP2040 I have on my TinyFAN PCB board, I have never seen it go into sleep mode. I only have the problem when my Raspberry Pi running Klipper loses the USB connection to the RP2040 board when it is powering up from a power down state or when the Raspberry Pi needs to reboot.

In my previous post, I said I would try my next idea of using a Digital Relay in series with the button so that I could remotely control the RESET action via software.

Please see the following link which has the working "work-a-round" to this RESET problem. The link to the solution is at https://github.com/Gi7mo/TinyFan/issues/8#issuecomment-1284904961

I created two different ways to solve this issue:

1. use a physical button to manually RESET the RP2040 USB connection
2. use a 5V Digital NC relay in conjunction with a python script (which runs automatically before Klipper is booted, or rebooted) or use PHP web URL's with a .html page that displays buttons on your web browser that you can press manually to control the 5V Relay.

Since I added the python script file to etc/rc.local file every time the Pi boots or reboots I no longer use the physical RESET button. The python script causes the relay to toggle USB port (just like the physical button did).

The provided link (https://github.com/Gi7mo/TinyFan/issues/8#issuecomment-1284904961) gives you the wiring diagram and the step by step instructions on how to install the python script (also the python script is provided) and how to create the .html code for the software button.

[boanerges57]

I think the issue with the pico isn't so much that there are issues that can be fixed by the community creating hardware and firmware solutions, but that the company that makes it doesnt seem to want to acknowledge and fix it themselves.

It isn't my issue anymore since my pico had a short in the pcb and caught fire. They won't even return my emails about it even though I'm not even seeking a replacement but just wanted to let them know my findings after I dissected my board and probed around with a multimeter.

These issues are shoddy design and poor testing. Pico is a great idea but terrible execution.

[NAPCAL]

@boanerges57 the issue is with the RP2040, not just with the BTT SKR Pico (RP2040), I am using an RPi Pico (RP2040) for extra GPIO, and it also goes to sleep running Klipper and resetting or unplugging the USB and reconnecting the USB are the only ways to wake it up.

[nmavor]

switch from USB to UART using nanopi NEO so far from not working never after restart (using USB) im at no issues at all for last 4 days

[Links2004]

running in the same problem here:

[ 1287.648606] usb 1-1-port4: attempt power cycle
[ 1288.308192] usb 1-1.4: new full-speed USB device number 17 using xhci_hcd
[ 1288.308496] usb 1-1.4: Device not responding to setup address.
[ 1288.528394] usb 1-1.4: Device not responding to setup address.
[ 1288.748192] usb 1-1.4: device not accepting address 17, error -71
[ 1288.848181] usb 1-1.4: new full-speed USB device number 18 using xhci_hcd
[ 1288.848445] usb 1-1.4: Device not responding to setup address.
[ 1289.068405] usb 1-1.4: Device not responding to setup address.
[ 1289.288163] usb 1-1.4: device not accepting address 18, error -71
[ 1289.288556] usb 1-1-port4: unable to enumerate USB device
[ 1289.598192] usb 1-1.4: new full-speed USB device number 19 using xhci_hcd
[ 1289.698420] usb 1-1.4: device descriptor read/64, error -32
[ 1289.918466] usb 1-1.4: device descriptor read/64, error -32
[ 1290.138176] usb 1-1.4: new full-speed USB device number 20 using xhci_hcd
[ 1290.238404] usb 1-1.4: device descriptor read/64, error -32
[ 1290.458439] usb 1-1.4: device descriptor read/64, error -32
[ 1290.578788] usb 1-1-port4: attempt power cycle
[ 1291.248193] usb 1-1.4: new full-speed USB device number 21 using xhci_hcd
[ 1291.248459] usb 1-1.4: Device not responding to setup address.
[ 1291.478406] usb 1-1.4: Device not responding to setup address.
[ 1291.698240] usb 1-1.4: device not accepting address 21, error -71
[ 1291.798362] usb 1-1.4: new full-speed USB device number 22 using xhci_hcd
[ 1291.798616] usb 1-1.4: Device not responding to setup address.
[ 1292.018491] usb 1-1.4: Device not responding to setup address.
[ 1292.238195] usb 1-1.4: device not accepting address 22, error -71
[ 1292.238600] usb 1-1-port4: unable to enumerate USB device

[boanerges57]

That was my config but I did later figure out that one of the uarts was a debug uart for the rp2040. The board worked better using USB to control it than uarts - much more reliable connection - under uart it was fiddly to connect to and sometimes randomly lost connection. My board burned up so I have an e3 v3 on that printer now.

They should stop advertising the uart features and tell people to use USB. The pico on uart is a pita that could easily be avoided by using USB.

On Tue, Aug 30, 2022, 9:28 AM Fraser @.***> wrote:

would you be able to share your exact cfg for the mcu section, I tried putting mine as:

[mcu] serial: /dev/ttyAMA0 serial: /dev/ttyS0 restart_method: command

but doesn't work

— Reply to this email directly, view it on GitHub https://github.com/bigtreetech/SKR-Pico/issues/2#issuecomment-1231747447, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2Z44T36U2JJYTDQ7NNPEETV3YK77ANCNFSM5NEVJ2AQ . You are receiving this because you commented.Message ID: @.***>