Somewhere between commit g37315bf3 and commit g645a1b83 it appears a regression was introduced. UART communication with the TMC driver on an SB2040 no longer functions. Log attached with a DUMP_TMC from each commit.
klippy-3.log (417.5 KB)
1 Like
Itās only the extruder UART that gives an error:
TMC extruder failed to init: Unable to read tmc uart 'extruder' register IFCNT
Unable to read tmc uart 'extruder' register GCONF
So it canāt be a bug, else the other steppers would be affected too.
You may check the extruder TMC stepper driver wiring and/or pin assignment.
BTW: The printer.cfg looks quite wild.
Sometimes less is more.
It is a bug. With most recent host code and older MCU code the extruder works. After flashing MCU to most recent commit the extruder stops working. I have not flashed my other MCUs to confirm if itās only a problem with the rp2040, or if other MCUs are affected. Iām reporting here because multiple people have confirmed this problem including me.
2 Likes
Iām also not looking to get into an argument, but many of your replies here are not helpful. Iāve been using Klipper for 6 years and Iām a helper on the Discord. I donāt need your advice about the macros I use or how my printer is configured.
I just wanted to confirm that this is a bug.
I have this problem on two printers with mellow sb2040 v1 and v2.
Both of them work fine with an older commit and stop working with the current version.
1 Like
Unfortunately, this seems like it will be difficult to track down as nothing has changed to the tmcuart code recently. At first glance it seems likely to be an obscure interaction with the rp2040 build. I donāt have an rp2040 with tmcuart drivers readily available.
It would help if someone with the impacted hardware could identify the exact commit that is causing the regression. (Either by using git bisect or by checking out each of the commits in the range and finding which commit is the first one to cause the problem.)
Iād also need to see the klipper log with the M112 run immediately after the TMC driver error (so that the log contains the raw messages sent to/from the rp2040).
-Kevin
User locki on discord reported:
Hi, last .219 broke mellow SB2040 boards
rollback to .218 solved issue
This points to PR #6141.
Although I donāt see any obvious interaction between the i2c and tmc_uart code.
I really need to see the logs from the events in order for me to have any hope of tracking it down. (With M112 run immediately after the error.)
If it is thought to be the āsoftware spiā commit (645a1b83) then one thing to try would be to disable i2c on the rp2040. This can be done by modifying src/rp2040/Kconfig and change the line select HAVE_GPIO_I2C to #select HAVE_GPIO_I2C, then run make menuconfig, save and exit, run make, and flash the micro-controller again. Report the results here.
-Kevin
Iām out of town for two weeks, so hopefully someone else can do these tests and produce a better log. I ran M112, but it wasnāt until a couple minutes after the error. If itās not resolved before I get back I can provide all of this info.
klippy(2).log (235.9 KB)
I hope this helps.
I also recompiled and reflashed with select HAVE_GPIO_I2C commented out and now the extruder works!
I am on 645a1b83.
edit: Immediately after posting this, klipper on the sb2040 seems to have crashed or something, because no commands that affect the sb2040 were accepted, but this was fixed after another firmware_restart.
1 Like
Thanks.
One more quick test - if you go back to the pristine code, pull the very latest code, run āmake menuconfigā, and reflash does it still fail? If so, if you apply the following change, run āmake menuconfigā and reflash, does it still fail?
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -103,6 +103,7 @@ config WANT_SENSORS
config WANT_SOFTWARE_I2C
bool
depends on HAVE_GPIO && HAVE_GPIO_I2C
+ depends on !MACH_RP2040 # Temporary hack to avoid rp2040 regression
default y
config WANT_SOFTWARE_SPI
bool
-Kevin
So with the current commit 6ce2bd61 without changes it works.
But with the additional line in src/Kconfig it also works.
Not sure if this helps.
Thanks for testing and providing feedback.
Just to be clear, you are reporting that the latest Klipper master release ( 6ce2bd61c ) without any changes at all (no changes to src/Kconfig nor src/rp2040/Kconfig) is working again on the rp2040?
Very strange - definitely sounds like an obscure build interaction of some kind on the rp2040.
-Kevin
I have encountered similar issues, with a SKR Pico in USB CAN Bus Bridge Mode.
On v0.11.0-221-g6ce2bd61, Klipper would immediately crash after issuing G28.
I tried your !MACH_RP2040 hack on g6ce2bd61, with same result - crash immediately after starting any movement. klippy.log with M112 after crash is attached.
I previously was on g645a1b83, and it looked fairly promising, but partway through a print, it failed with Unable to read tmc uart 'stepper_x' register IFCNT (Iām pretty sure).
I now went down to v0.11.0-218-gb389c70d, and it homes just fine, and I am about to start a print.
Edit: print using v0.11.0-218-gb389c70d on the SKR Pico completed without shutdown.
klippy.log (159.2 KB)
Sorry, I got sick and kinda forgot about this.
Yes, I can confirm that I could not reproduce the problem anymore. I have another printer with a sb2040 and old klipper version on it, I could try again on that one.
I had same issue in v0.11.0-239-ga96608ad TMC_DUMP stepper=extruder on my mellow fly board would emit: Unable to read tmc uart āextruderā register GCONF
uncommenting #select HAVE_GPIO_I2C in src/rp2040/Kconfig fixed the problem.
In answer to koconnor:
I am using a SKR PICO and EBB36.
my last build (gd32a8334) worked on the EBB36 but did not on the PICO
The latest build (g6d48adf9) fails on the PICO
but adding ādepends on !MACH_RP2040 # Temporary hack to avoid rp2040 regressionā on the PICO works.
latest master build:
klippy (5).log (28.4 KB)
latest master build (g6d48adf9) with ādepends on !MACH_RP2040ā added :
klippy (6).log (19.0 KB)
Apologies for poor format earlier.
There have been a few people reporting issues with the latest rp2040 build, but it seems the vast majority of users are not having an issue. Nothing in the rp2040 nor tmc uart code has changed recently. At best guess there is some kind of strange compiler interaction. So, Iām not sure what is the root cause of the issue is, but I also have no way to track it down.
If you are experiencing an issue, you might want to try noting your current configuration in make menuconfig, run make distclean, run make menuconfig, set the appropriate parameters again, then build and flash the firmware.
-Kevin