V0.13.0-549 on Flsun Super Racer, no joy (and much pain)

General Discussion
1

Basic Information:

Printer Model: FLSUN SUPER RACER
MCU / Printerboard: MKS Robin Nano V3
Host / SBC Raspberry PI 3B
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:

It was some weeks i didn’t use the printer.

Turn on, run kiauh, there are updates, going for it, as usual.

Going on Fluidd, it tells me that:

‘mcu’ has deprecated code (it is
missing feature
‘STEPPER_STEP_BOTH_EDGE’
Recompiling and flashing is recommended

ok, time for a flash update (v0.13.0-549-g016474b68).

cd klipper
make menuconfig

Made sure to set everything as usual, then i checked the relevant option about the stepper step both edge.

Reboot raspi, reboot printer.

Raspi hangs up.

Tried again, same story.

Disconnected the USB cable (from rapspi to the printer), raspi manages to finish loading. After that, connecting the cable, it sees the printer.

Tried the whole process again, same story: PI hangs if it finds the printer already on, it’s “ok” if i turn on the printer after PI is ready.

Ok, i have some urgent prints to do, so i start printing.

After like 20 minutes, printer stops and PI hangs.

“Ok, maybe it doesn’t like the stepper thing” i think.

I prepare another flash with that option uncheked, load it and…. same story.

To make thing shorter, i had to use Kiauh to roll back to v0.13.0-349, re-make the firmware, re-flash the printer and, voilà, it’s working again as usual.

No idea wich was the last working version, to go to 0.13.0-349 i just inputted in kiauh to roll back 100 commits (to be “sure”).

I’m attacching the klippy.log, hope somethingt hintful was captured there.

C.

klippy.log.zip (669.5 KB)

2

Hello @dhstsw !

And welcome to the forum.

As a first step it is recommended to get the MCU to the same Klipper version as the host:

Loaded MCU 'mcu' 124 commands (v0.11.0-304-gf7567a0d / gcc: (15:8-2019-q3-1+b1) 8.3.1 20190703 (release) [gcc-8-branch revision 273027] binutils: (2.34-4+rpi1+14) 2.34)
                               ^^^^^^^^^^^
MCU 'mcu' config: ADC_MAX=4095 BUS_PINS_i2c1=PB6,PB7 BUS_PINS_i2c1a=PB8,PB9 BUS_PINS_i2c2=PB10,PB11 BUS_PINS_i2c2a=PH4,PH5 BUS_PINS_i2c3=PA8,PC9 BUS_PINS_i2c3a=PH7,PH8 BUS_PINS_sdio=PC12,PD2,PC8,PC9,PC10,PC11 BUS_PINS_spi1=PA6,PA7,PA5 BUS_PINS_spi1a=PB4,PB5,PB3 BUS_PINS_spi2=PB14,PB15,PB13 BUS_PINS_spi2a=PC2,PC3,PB10 BUS_PINS_spi2b=PI2,PI3,PI1 BUS_PINS_spi3=PB4,PB5,PB3 BUS_PINS_spi3a=PC11,PC12,PC10 CLOCK_FREQ=168000000 MCU=stm32f407xx PWM_MAX=255 RESERVE_PINS_USB=PA11,PA12 RESERVE_PINS_crystal=PH0,PH1 STATS_SUMSQ_BASE=256 STEPPER_BOTH_EDGE=1
Configured MCU 'mcu' (1024 moves)
Args: ['/home/pi/klipper/klippy/klippy.py', '/home/pi/printer_data/config/printer.cfg', '-I', '/home/pi/printer_data/comms/klippy.serial', '-l', '/home/pi/printer_data/logs/klippy.log', '-a', '/home/pi/printer_data/comms/klippy.sock']
Git version: 'v0.13.0-464-g48f0b3cad'
              ^^^^^^^^^^^
Branch: master
Remote: origin
3

Thanks,

I tried to locate the log where problems started to happened but i guess i went back too much.

Beside that, the problem is not from current MCU, is with kilpper 549 and MCU 549.

(see current klippy.log, the one i attacched should have contained the problematic versions).

As you will see with the one i’m attacching here, i tried various ones.

As i said, at the moment i’m at 349 for both klipper and flash without problems.

Thx.

klippy.zip (727.5 KB)

4

Is the host OS fully updated? sudo apt satisfy couldn’t hurt.

One more data point would be:
Host on 349
MCU on 549

Perhaps the MCU will then toss an error that 349 on the host will handle and not crash.

Baring that you’ll have to dig into the host OS with dmesg

5

Yes, OS is fully updated.Also, when problem happened, both host and MCU where on 549.

pi@fluiddpi:~ $ sudo apt update
Hit:1 Index of /debian bookworm InRelease
Get:2 Index of /raspbian bookworm InRelease [15.0 kB]
Fetched 15.0 kB in 1s (11.4 kB/s)
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
All packages are up to date.
W: http://raspbian.raspberrypi.com/raspbian/dists/bookworm/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/

6

The question is if the MCU is doing something to crash the Pi or if code changes in 549 are crashing the Pi due to an Host side bug? If running the mismatched versons still crashes the bug is (most likely) in the MCU. If it runs then the bug is in the host side changes between 349 and 359.

Adding a delay to starting the host side klipper service to allow the USB connection “settle” may be a solution for the boot up issue but probably won’t solve the mid print crash.

7

Welcome dhstsw,
why don’t you update Klipper on both? MCU and host! Should solve your problems.

1 Like
8

That’s exactly what caused the problem: 549 host + 549 MCU = crash.

9

As for the klippy.log it is:

MCU Protocol error

This is frequently caused by running an older version of the
firmware on the MCU(s). Fix by recompiling and flashing the
firmware.

Your Klipper version is: v0.13.0-349-g3215e3a2a
MCU(s) which should be updated:
mcu: Current version v0.13.0-549-g016474b68

You may update the host to 549

This is the resulting issue in te moment.

mcu 'mcu': Unable to encode: query_analog_in
10

I ran your log through Claud AI to trim it down to host and MCU version changes.

| Line | Event Type | Component | Version | Notes |
|-----:|-----------|-----------|---------|-------|
| 882 | MCU Loaded | MCU firmware | v0.11.0-304-gf7567a0d | Old firmware, pre-update |
| 886 | Host start | Klipper host | v0.13.0-540-g57c2e0c96 | First session — major mismatch with MCU |
| 894 | Client connect | Moonraker | v0.10.0-8-g293a4cf | |
| 1019 | Client connect | Moonraker | v0.10.0-9-g3fbe6ee | Moonraker updated |
| 1142 | Host start | Klipper host | v0.13.0-572-g88a71c3ce | Host updated to 572 |
| 2044 | MCU Loaded | MCU firmware | v0.11.0-304-gf7567a0d | Still old MCU — mismatch continues |
| 3034 | MCU Loaded | MCU firmware | v0.11.0-304-gf7567a0d | Still old MCU |
| 4288 | MCU Loaded | MCU firmware | v0.11.0-304-gf7567a0d | Still old MCU |
| 5232 | MCU Loaded | MCU firmware | v0.11.0-304-gf7567a0d | Still old MCU |
| 5325 | Host start | Klipper host | v0.13.0-572-g88a71c3ce | |
| 6223 | MCU Loaded | MCU firmware | v0.13.0-572-g88a71c3ce | ✅ MCU now flashed to 572 — versions match |
| 6289 | Host start | Klipper host | v0.13.0-572-g88a71c3ce | |
| 7189 | MCU Loaded | MCU firmware | v0.13.0-572-g88a71c3ce | |
| 9538 | Host start | Klipper host | v0.13.0-572-g88a71c3ce | |
| 10436 | MCU Loaded | MCU firmware | v0.13.0-572-g88a71c3ce | |
| 10602 | **⚠ CRASH** | MCU | — | `Lost communication with MCU 'mcu'` |
| 10625 | **⚠ SHUTDOWN** | MCU | — | `MCU 'mcu' shutdown` |
| 10830 | **⚠ ERROR** | MCU | — | `Lost communication with MCU 'mcu'` |
| 11817 | MCU Loaded | MCU firmware | v0.13.0-572-g88a71c3ce | Recovery attempt |
| 12257 | Host start | Klipper host | v0.13.0-572-g88a71c3ce | |
| 13341 | Last MCU build | MCU firmware | v0.13.0-572-g88a71c3ce | |
| 14235 | MCU Loaded | MCU firmware | v0.13.0-572-g88a71c3ce | |
| 23007 | Host start | Klipper host | v0.13.0-572-g88a71c3ce | |
| 23906 | MCU Loaded | MCU firmware | v0.13.0-572-g88a71c3ce | |
| 24252 | **⚠ CRASH** | MCU | — | `Lost communication with MCU 'mcu'` |
| 24275 | **⚠ SHUTDOWN** | MCU | — | `MCU 'mcu' shutdown` |
| 24480 | **⚠ ERROR** | MCU | — | `Lost communication with MCU 'mcu'` |
| 25463 | MCU Loaded | MCU firmware | v0.13.0-572-g88a71c3ce | |
| 25534 | Host start | Klipper host | v0.13.0-572-g88a71c3ce | |
| 26621 | Host start | Klipper host | v0.13.0-569-g94604293e | ⬇ Host rolled back to 569 |
| 27705 | Last MCU build | MCU firmware | v0.13.0-569-g94604293e | MCU built at 569 |
| 27711 | Host start | Klipper host | v0.13.0-549-g016474b68 | ⬇ Host rolled back to 549 |
| 28795 | Last MCU build | MCU firmware | v0.13.0-549-g016474b68 | MCU built at 549 |
| 28801 | Host start | Klipper host | v0.13.0-549-g016474b68 | |
| 29697 | MCU Loaded | MCU firmware | v0.13.0-572-g88a71c3ce | ⚠ MCU still on 572 — mismatch with 549 host |
| 30592 | MCU Loaded | MCU firmware | v0.13.0-572-g88a71c3ce | |
| 30699 | Host start | Klipper host | v0.13.0-549-g016474b68 | |
| 31600 | MCU Loaded | MCU firmware | v0.13.0-572-g88a71c3ce | |
| 31647 | Host start | Klipper host | v0.13.0-549-g016474b68 | |
| 32543 | MCU Loaded | MCU firmware | v0.13.0-549-g016474b68 | ✅ MCU flashed to 549 — versions match |
| 32649 | Host start | Klipper host | v0.13.0-549-g016474b68 | |
| 33733 | Last MCU build | MCU firmware | v0.13.0-549-g016474b68 | |
| 33739 | Host start | Klipper host | v0.13.0-349-g3215e3a2a | ⬇ Host rolled back to 349 |
| 34825 | Host start | Klipper host | v0.13.0-349-g3215e3a2a | |
| 35723 | MCU Loaded | MCU firmware | v0.13.0-549-g016474b68 | ⚠ MCU still on 549 — mismatch with 349 host |
| 35762 | MCU version note | MCU firmware | v0.13.0-549-g016474b68 | Reported as current |
| 35906 | Last MCU build | MCU firmware | v0.13.0-349-g3215e3a2a | MCU now built at 349 |
| 36802 | MCU Loaded | MCU firmware | v0.13.0-549-g016474b68 | ⚠ Still loading old 549 flash |
| 36841 | MCU version note | MCU firmware | v0.13.0-549-g016474b68 | |
| 36985 | Last MCU build | MCU firmware | v0.13.0-349-g3215e3a2a | |
| 36991 | Host start | Klipper host | v0.13.0-349-g3215e3a2a | |
| 37887 | MCU Loaded | MCU firmware | v0.13.0-349-g3215e3a2a | ✅ Both at 349 — stable from here |
| 37958 | Host start | Klipper host | v0.13.0-349-g3215e3a2a | |
| 38852 | MCU Loaded | MCU firmware | v0.13.0-349-g3215e3a2a | ✅ Stable |

Afterwards it spit out the following:

The STEPPER_OPTIMIZED_EDGE=21 flag and the jump in PWM_MAX from 257 to 32768 are both absent in the stable 349 build. Either or both could be triggering a timing issue on the MKS Robin Nano V3’s GD32F407-equivalent MCU. The PWM_MAX jump from 257 to 32768 is particularly notable — that’s a 128× change in PWM resolution that would affect all heater/fan control timing.
This is worth reporting to the Klipper issue tracker with the specific build config diff, as it looks like a genuine regression on this board.

Way above my ability to confirm but I know GigaDevices are not as stable as STM.

@nefelim4ag @koconnor any ideas?

11

Thx.
When i went back to 349 i purposely avoided to enable the stepper flag when compiling the flash (since it kept crashing on upper versions - even if now i think it’s unrelated).

At least you can see i’ve been on 549 on both MCU and HOST (→crashes).

I’ll try again when i can without disrupting my printer use.

Thanks.

12

klippy.zip (205.8 KB)

Tried again, went on -572 (HOST + MCU), same result. It hangs.
Klippy.log attacched.

13

I would try a fresh SD card.

14

Whatever is happening, the initial statement sounds like follows:

  • New version of user space software “notepad” (klippy host), makes the host hang
  • New version of MCU firmware for USB-connected peripheral makes the host hang (I got a new flash drive, and it makes my PC hang).

Whatever is happening, neither the host-side code nor the firmware side can do that.

IIRC, RPI3 has some USB quirks, and the only known workaround to me is DWC2, whatever option: PI freezes after setting mcu USB id - #8 by Sineos

Hope that helps,
-Timofey

16

I would try a fresh SD card.

Tried, both host and mcu, no joy.

17

No probs with earlier versions of host and mcu (349).

I’ll try with DWC2 and i’ll report.

EDIT:

With dtoverlay=dwc2 under [all] in config.txt USB camera doesn’t connect anymore, so it’s not an option.

18

From the link above

The GD32F407 MCU is known to be less than 100% equivalent to the STM chips. It seems to me that the latest MCU code changes could push it into the “Deffective hardware” category.

If that is the case the OS on the Pi SHOULD gracefully handle the issue and raise an error flag and continue to run. We all know there are always edge cases where that doesn’t happen.

@dhstsw Do you have any other hardware you can temporally substitute for the Pi3B? In the past I have installed Linux (Debian) on a flash drive (you need 2, one for the bootable installer and 1 for the destination drive) to avoid having to actually dual boot my PC. If the MCU fails attached to a different host that would help sort out your issue.

19

@cardoc
Do you have any other hardware you can temporally substitute for the Pi3B? In the past I have installed Linux (Debian) on a flash drive (you need 2, one for the bootable installer and 1 for the destination drive) to avoid having to actually dual boot my PC. If the MCU fails attached to a different host that would help sort out your issue.

I should have a PI2B somewhere. Would that make any difference?

20

Worth a try. But getting a non RPi USB host would hopefully better determine if the GD32F407 can run the MCU code.

It just occurred to me it is possible to use Pi GPIO pins to connect direct serial to the MCU board. I’ve never done it but would be a good way to waste a day if your into esoteric configurations.

Pi3B to Nano V3 serial.pdf (73.2 KB) AI generated use with caution!

21

@cardoc
So, i installed debian 13 on an old laptop, klipper 572, flashed the printer and of course it connects.

klippy.zip (30.3 KB)

Attacched the relevant log (at start it won’t find the printer, then it finds it with mismatched MCU flash, then it will be with matched flash.

So i guess the problem is in the firmware of the PI3B.

Do you have any idea if RPI5 have the same issue? (i can’t use a laptop, wich btw barely starts, to drive the printer).

Or any other idea beside DWC2 (wich creates other issues) to fix the RPI3?

Thanks.