BTT Eddy not working after powercycle with latest klipper version

General Discussion
1

Basic Information:

Printer Model: Neptune 4 Pro
MCU / Printerboard: Elegoo stock
Host / SBC: OpenNept4une (main branch commit 47405545)

Describe your issue:

After compiling and flashing latest klipper to the BTT Eddy (RP2040) it works just fine, it’s detected by the OS and registered as a serial device.
As soon as the BTT Eddy is powercycled, this is no longer the case, the device is not registered by the OS atall (syslog, dmesg) and no serial device is available.
Klipper shows the following error message:

mcu 'eddy': Unable to connect
Once the underlying issue is corrected, use the
"FIRMWARE_RESTART" command to reset the firmware, reload the
config, and restart the host software.
Error configuring printer

Reflashing klipper to the Eddy makes it work again until next powercycle.

The problem seems to arise with commits after edc3d34b, right now I’m running v0.12.0-441-gedc3d34be without any problems.

PS: Sorry for not posting a klipper.log, I’d have to get my system into non-fiunctional state again for this… took me a coule of hours to get it to work again.

PPS: The Eddy does not show up on any host I tested with the faulty klipper version after flashing and powercycling.

There seems to be an issue on the BTT github for this but since support got merged into official klipper I guess it has to be fixed here.

1 Like
2

Thank you for the report and issue investigation.
It is probably can be caused by rp2040: set clock to 200Mhz · Klipper3d/klipper@2f6d240 · GitHub

The problem is, I can not reproduce it on my development board, it is happily going to a shutdown state and happily performing reset by command.

Also, there are no schematics on the BTT side.

By revising the original PICO-SDK commit:

I think post div should not matter, it is 6 and 1 in SDK, and 3 and 2 computed in the MCU code, so the total value is still 6.

So, the only difference that I’m able to spot is a busy loop after updating the voltage:

vreg_set_voltage(SYS_CLK_VREG_VOLTAGE_MIN);
 // wait for voltage to settle; must use CPU cycles as TIMER is not yet clocked correctly
busy_wait_at_least_cycles((uint32_t)((SYS_CLK_VREG_VOLTAGE_AUTO_ADJUST_DELAY_US * (uint64_t)XOSC_HZ) / 1000000));

It is strange, because I expect it to be not able to initialize on the boot.

It would be nice to get the actual Btt Eddy frequency from the logs, I suspect if it is higher than 12Mhz, then, maybe there is enough to just increase voltage farther a little.

diff --git a/src/rp2040/main.c b/src/rp2040/main.c
index 607498d17..d6bb3bffa 100644
--- a/src/rp2040/main.c
+++ b/src/rp2040/main.c
@@ -69,7 +69,7 @@ void set_vsel(void)
     // Set internal voltage regulator output to 1.15V on rp2040
 #if CONFIG_MACH_RP2040
     uint32_t cval = vreg_and_chip_reset_hw->vreg;
-    uint32_t vref = VREG_AND_CHIP_RESET_VREG_VSEL_RESET + 1;
+    uint32_t vref = VREG_AND_CHIP_RESET_VREG_VSEL_RESET + 2;
     cval &= ~VREG_AND_CHIP_RESET_VREG_VSEL_BITS;
     cval |= vref << VREG_AND_CHIP_RESET_VREG_VSEL_LSB;
     vreg_and_chip_reset_hw->vreg = cval;

If delay is really necessary, I suspect this should do the trick:

diff --git a/src/rp2040/main.c b/src/rp2040/main.c
index 607498d17..52a73f763 100644
--- a/src/rp2040/main.c
+++ b/src/rp2040/main.c
@@ -154,9 +154,9 @@ clock_setup(void)
                          | RESETS_RESET_PADS_QSPI_BITS);
 
     // Setup xosc, pll_sys, and switch clk_sys
+    set_vsel();
     xosc_setup();
     enable_pclock(RESETS_RESET_PLL_SYS_BITS);
-    set_vsel();
     pll_setup(pll_sys_hw, FBDIV, FBDIV * FREQ_XOSC / FREQ_SYS);
     csys->ctrl = 0;
     csys->div = 1<<CLOCKS_CLK_SYS_DIV_INT_LSB;

Hope that helps.

3

Thank you for the quick reply.

I have a print running right now, but I will try the proposed patches later or tomorrow and let you know if this fixes the issue.

4

Hi @nefelim4ag

I tested your patch and can confirm that the first patch fixes the problem with BTT Eddy.
Thanks again for the quick reply and fix, I hope that this will make it to the repo soon.

Have a nice day
r3cliq

5

Glad to hear,
It feels a little wrong to me, to rump up the voltage farther.

It would be helpful if you shared your Klippy log, so I can guess the actual frequency and I may humbly ask you to try the second one.

Then I can easily make a PR and link that issue as a source.

Thanks.

6

Sure I can try that…

So just the second patch or both applied?

7

Those are isolated changes, so only the second one.
I hope that will give us an idea of what is happening underneath.
If the second one helps, that means there is not enough time to stabilize power before ramping up the CPU frequency.

Thanks.

8

I just did some more test and compiled three versions, one for each patch and one with both patches, neither of them seems stable…
If i turn the Eddy off for a couple of seconds (unplug USB) it won’t come back most of the times, no matter with which version.

Attached is a klippy.log with Eddy attached with the second patch.
klippy.log (215.7 KB)

Maybe an option to choose the RP2024 speed is needed for devices having problems with 200 MHz?

9

Just a wild guess, can you please try to set Flash chip CLKDIV to 4?
125 / 2 = 62.5Mhz
200 / 4 = 50Mhz

[*] Enable extra low-level configuration options
    Micro-controller Architecture (Raspberry Pi RP2040/RP235x)  --->
    Processor model (rp2040)  --->
    Bootloader offset (No bootloader)  --->
    Flash chip (GENERIC_03H with CLKDIV 4)  --->
    Communication Interface (USBSERIAL)  --->
    USB ids  --->
[*] Optimize stepper code for 'step on both edges'
()  GPIO pins to set at micro-controller startup

That is it, if patches do not help, I think maybe there is just an inappropriate QSPI Flash chip for that clock frequency.

Thanks.

JFYI, according to logs, the oscillator clock frequency is fine ~12_000_625.

1 Like
10

This seems to do the trick!

Compiled without any of the patches but with CLKDIV 4 and so far the Eddy becomes alive every time and powercycle.

I think this setting is the solution.

1 Like