RP2040 MCU does not connect until reset is pressed

[JoaquinBerrios]

The ERB board fails to connect to the host at boot until the reset button is pressed and the klipper service is re-started. This appears to be the same issue mentioned in the BTT SKR-Pico issue named here: bigtreetech/SKR-Pico#2

I was able to implement a similar workaround as that mentioned in the thread and described in more detail here:
https://github.com/Drachenkaetzchen/VoronMisc/blob/main/SKR-Pico-Reset.md
by connecting pin 3 in P1 to a GPIO pin on my the host raspberry pi and resetting the ERB at boot time before the klipper service starts, but would prefer an actual fix that would allow me to undo that hack.

[matthewj301]

yup also having this issue, although intermitently

[JoaquinBerrios]

Looks like this was addressed in a commit last week in Klipper. I built firmware for a couple of RP2040 boards using the fixed usbserial.c from this commit and they connect via USB with no issues so far. Just thought I would share for other having this issue to try and see if this resolves it for them.
Klipper3d/klipper@bec1d95

[PatrikTheDev]

I’m running the latest Klipper version (both ERB and Pi) and I’m still having issues, though mine doesn’t connect after a reset, it often needs MUCH more convincing. I already requested a partial refund but is there a way to save the board? That Klipper commit didn’t work for me since I’m running it already

[mk-maddin]

@PatrikTheDev
I was able to resolve this issue by flashing with the following options - Klipper v0.11.0-221-g6ce2bd61

[PatrikTheDev]

IIRC that’s what I flashed with before but it didn’t work. I got it working with the CanBoot workaround though. As it turns out the board still wasn’t quite healthy (TMC undervoltage errors when doing sensorless homing) and I got a partial refund from Fysetc

[mk-maddin]

ok...maybe I was a bit too fast - I am now running into "Timeout on wait for 'tmcuart_response' response" error on like every seconds stepper_buzz command
Re-flashing with the default chip "W25Q080 with CLKDIV 2" solves the stepper_buzz error, but again causes disconnect at every restart

[PatrikTheDev]

Have you tried flashing CanBoot to it yet? Seems to also work for the SKR Pico

[mk-maddin]

No not yet ...
I am not using CanBus at all at the moment and after reading through the CanBoot guideline, to be truth I have no idea how to "2. Build klipper wiht CAN support" ( https://github.com/Arksine/CanBoot#uploading-klipper )

[PatrikTheDev]

I’m not using CAN either right now, CanBoot offers a USB mode. Look into the SKR Pico repo, issue number 2 for more information

[mk-maddin]

To be truth I am not 100% sure if I really see the same issue as the skr pico people describe ...
My device does not show at all within /dev/serial/* or /dev/tty* after every RST or power disconnect of 24V,
until I re-flash a .uf2 via the "storage" (pressing "bootsel"+"rst") mode.
I can press "rst" during boot or run the GPIO workaround - all without any success unti I re-flash and keep the device online.

So klipper not able being to connect is only a "victim" of the ERB not correctly booting into the flashed firmware / serial mode after power off / reset.
This happens as I just tested for klipper.uf2 as for canboot.uf2

[jeanres]

Same issue here.

[mk-maddin]

I think I was able to solve the issue for me now by using the same flash procedure as done with the 3D Mellow Fly ERCF Easy BRD board ( https://mellow.klipper.cn/#/board/fly_ercf/flash ) - as most of this is chinese and I had to translate via online translator service - here is what I did:

1. Prepare Firmware

On your klipper device (usually Raspberry Pi) run the following to create your make configuration:
cd ~/klipper
make clean
make menuconfig

Select the following menuconfig settings

And create the firmware files by running the following:
make

2. Connecting the board and bring it into flash mode

Step 1: Connect 24V (Power on the board)
Step 2: Connect USB-C cable to your klipper device (usually Raspberry Pi)
Step 3: Push an hold BOOTSEL button
Step 4: Click RST button
Step 5: Release RST and BOOTSEL button at the same time

Verify your device is in boot mode connected by running the following command:
lsusb

The output should contain an entry looking like 2e8a:0003 Raspberry Pi RP2 Boot

3. Flashing the firmware

Now we do not flash the fimware by directly copying it to the storage, but we flash it using the following command:
make flash FLASH_DEVICE=2e8a:0003
The output looks like the following - IF you are prompted (you might or might not) for a password, enter the password of your current user account.

Now restart your fystec-erb by disconnecting 24V - waiting some seconds and reconnecting 24V again.
You should be able to see it as usual klipper device within /dev/serial/by-id

Hope this helps :)

EDIT: The klipper version I used is the latest at the time being ( v0.11.0-239-ga96608ad ) - I did not test with older version.

[Erfa1l]

Got the same issue on Klipper v0.11.0-240-g6d48adf9, Everytime when printer reboots I need to manualy disconnect usb -> press RST for a couple of second -> plug USB in. Only this steps help raspberry pi 4 to recognize device.. The hack from 1st post is not working for me :(

[Mapiiik]

We have also problems with ERB v1.1 board. With Flash chip (W25Q080 with CLKDIV 2) board boot only after imediate flash and reboot. After power off/on we can't achieve USB connection even if we tried with pressing RST/disconnecting/connecting.

With Flash chip (GENERIC_03H with CLKDIV 4) board boots OK every time, but is unusable, if we send any commands to it, it almost every time stops with
Timeout on wait for 'tmcuart_response' response

Has anyone managed to solve these problems?

[ammoniak]

Same thing here, it works after flashing but not after restarting/connecting it again, etc.

[tdlane1]

Encountering the same issue as Mapiik here, running Klipper v0.12.0-9

[jamseywood]

I am having the same issue, is there any update?

[ngandalf]

I am having the same issue with latest version of klipper :-( the workaround of JoaquinBerrios dosn't work for me i need to flash the erb board to detect the device with klipper

[salocain]

same issue , work well before, but....after 5v servo port dead, now.... connecting problem..... it's not a good product ....

fysetc do a commercial offer ?

[jamseywood]

so I have done some digging and it looks like the Pi chip is at fault here. There was a bug that caused the RP chip to not detect USB connections on boot randomly. Unfortunatly it looks like there is not real fix for this as we cannot change the low level code on the chip. There are hardware 'hacks' that require soldering a wire from the reset switch to an addressable pin where you can call a function to reset the board as needed, but not an ideal solution. I have moved over to the standard ERCF board and its been faultless, only issue being that every prin was backward, but easy enough to fix.

[salocain]

so I have done some digging and it looks like the Pi chip is at fault here. There was a bug that caused the RP chip to not detect USB connections on boot randomly. Unfortunatly it looks like there is not real fix for this as we cannot change the low level code on the chip. There are hardware 'hacks' that require soldering a wire from the reset switch to an addressable pin where you can call a function to reset the board as needed, but not an ideal solution. I have moved over to the standard ERCF board and its been faultless, only issue being that every prin was backward, but easy enough to fix.

can you give me a link for this hack explaination?

thank you

[jamseywood]

so I have done some digging and it looks like the Pi chip is at fault here. There was a bug that caused the RP chip to not detect USB connections on boot randomly. Unfortunatly it looks like there is not real fix for this as we cannot change the low level code on the chip. There are hardware 'hacks' that require soldering a wire from the reset switch to an addressable pin where you can call a function to reset the board as needed, but not an ideal solution. I have moved over to the standard ERCF board and its been faultless, only issue being that every prin was backward, but easy enough to fix.

can you give me a link for this hack explaination?

thank you

https://github.com/matthew-humphrey/3DP-Build-Log/blob/main/RP2040-USB-Bug/README.md

[JoaquinBerrios]

so I have done some digging and it looks like the Pi chip is at fault here. There was a bug that caused the RP chip to not detect USB connections on boot randomly. Unfortunatly it looks like there is not real fix for this as we cannot change the low level code on the chip. There are hardware 'hacks' that require soldering a wire from the reset switch to an addressable pin where you can call a function to reset the board as needed, but not an ideal solution. I have moved over to the standard ERCF board and its been faultless, only issue being that every prin was backward, but easy enough to fix.

I explain what pin to connect to in my post above from March 23. No need to solder anything and can be implemented by connecting the pin on the board to a free GPIO pin on the pi/host computer. The pin I reference in my post is the reset pin you need to connect to and is already routed to the header on this board. If you don't want to toggle with with a GPIO pin, you can also connect a manual switch that will short the pin to ground to reset manually, although that is more of a pain than automating the reset.

Also, the core issue with the RP2040 was addressed in a Klipper update some time back (see my post above on May 2). My board is still working fine for me running the current version of Klipper on my MCU so I wouldn't think it's regression of the issue. If you haven't flashed your board to the current version of Klipper, try that before hacking around with workarounds. You can check the version of Klipper on your MCUs in the "System" menu in Fluidd. I'm sure Mainsail has a similar screen where you can check the version of the firmware on your MCUs. If it's older than the commit I reference above, you will need to flash your board with the current version of Klipper.

This shouldn't make a difference, but I also flashed CanBoot/Katapult on my board since I have the board connected via CANbus. If you update to the current version of Klipper and your board still has the issue, try flashing Katapult, re-flashing Klipper and see if that helps. You can still connect the board via USB even if you flash it with Katapult, just build Klipper to connect via USB instead of CAN.

If all this doesn't work and you are considering a new board, take a look at the BTT MMU. It's bult on an STM controller, replaceable stepper drivers, and a ton of other features to better support the ERCF v2.