Marlin: TMC2130 Driver Error with commit 00d03c6

[th33xitus]

I downloaded and compiled the newest bugfix-1.1.x release (commit 00d03c6) and flashed it on my Mega2560+RAMPS1.4 with TMC2130 on X, Y, Z, E0 and E1. On bootup i instantly get a driver error and the printer halts.

I saw that you guys actually must have changed something regarding the sensorless homing function since i had to set X_MIN_ENDSTOP_INVERTING and Y_MIN_ENDSTOP_INVERTING both to true to even pass the sanity check and make my Arduino IDE compile it successfully.
All the releases before i had them set to false and sensorless homing worked flawless.

I then flashed an earlier bugfix-1.1.x release which i know is working (was a commit from march 17th), and it worked right away again. No driver error on bootup, so i can exclude my drivers and they don't seem faulty.

[marcio-ao]

@th33xitus : Yup. See #10294. The reason this was changed was that the default of using non-inverting endstops with sensorless homing could cause a short on certain boards. The default behavior was thus changed to avoid damaging those boards and the sanity check was added to inform people of the change.

Since you were able to get your printer working again, it seems like the sanity check worked as intended!

[marcio-ao]

On bootup i instantly get a driver error and the printer halts.

Oh, looks like I missed this part. So you did not get it to work after changing X_MIN_ENDSTOP_INVERTING and Y_MIN_ENDSTOP_INVERTING. What is the driver error?

[th33xitus]

Okay thx for the info on the change. And yes the sanity check worked just fine :D But as you just noticed that's not the major problem here.
To be honest: I don't know what is causing the driver error. I don't get another message other than "Driver error - Printer halted - please reset" on my display and in Octoprint the log tells me:
Recv: X driver error detected: Recv: overtemperature Recv: short to ground (coil A) Recv: short to ground (coil B) Recv: X Y Z E0 E1 Recv: Enabled false false false false false Recv: Set current 638 638 638 638 638 Recv: RMS current 611 611 611 611 611 Recv: MAX current 1557 862 862 862 862 Recv: Run current 19/31 19/31 19/31 19/31 19/31 Recv: Hold current 9/31 9/31 9/31 9/31 9/31 Recv: CS actual 31/31 31/31 9/31 9/31 9/31 Recv: PWM scale 255 255 1 1 2 Recv: vsense 1=.18 1=.18 1=.18 1=.18 1=.18 Recv: stealthChop true true true true true Recv: msteps 0 0 16 16 16 Recv: tstep 4278517759 4294967295 1048575 1048575 1048575 Recv: pwm Recv: threshold 79 79 395 276 1657 Recv: [mm/s] 0.00 0.00 5.00 30.03 5.00 Recv: OT prewarn true true false false false Recv: OT prewarn has Recv: been triggered false false false false false Recv: off time 1 15 5 5 5 Recv: blank time 24 54 24 24 24 Recv: hysteresis Recv: -end 12 12 2 2 2 Recv: -start 8 8 3 3 3 Recv: Stallguard thrs 26 26 0 0 0 Recv: DRVSTATUS X Y Z E0 E1 Recv: stallguard X X Recv: sg_result 1023 1023 0 0 0 Recv: fsactive X X Recv: stst X X X X X Recv: olb X X Recv: ola X X Recv: s2gb X X Recv: s2ga X X Recv: otpw X X Recv: ot X X Recv: Driver registers: X = 0xFF:FF:FF:C1 Recv: Y = 0xFF:FF:FF:FF Recv: Z = 0x80:09:00:00 Recv: E0 = 0x80:09:00:00 Recv: E1 = 0x80:09:00:00 Recv: Recv: Recv: Error:Printer halted. kill() called! Changing monitoring state from "Operational" to "Error: Printer halted. kill() called!" Changing monitoring state from "Error: Printer halted. kill() called!" to "Offline (Error: Printer halted. kill() called!)" Connection closed, closing down monitor

Whats funny is, that the log tells something about an overtemperature and a shortage to ground on both coils. Even though the driver wasn't even active, it didn't even had the chance to be activated since the printer was instantly killed after booting.

And since it works just fine with a previous bugfix-1.1.x, i can assure that there is no driver related issue. I can move my x-axis without any problems on the previous build so i can assure you that there is no shortage of any stepper coil.

[marcio-ao]

That's odd.

Do you know whether your board connects DIAG0 and DIAG1 from the Trinamic to different GPIO pins, or whether they are tied together? Not sure whether that is relevant, but I suppose I'll start by trying to understand more about your board.

@teemuatlut : Any thoughts on this?

[th33xitus]

Do you know whether your board connects DIAG0 and DIAG1 from the Trinamic to different GPIO pins, or whether they are tied together?

I guess i have to pass on this question since my knowledge of this kind of stuff isn't advanced enough, im sorry.

[marcio-ao]

@th33xitus: Do you have #define ENDSTOPPULLUPS enabled in Configuration.h and/or ENDSTOPPULLUP_XMIN and ENDSTOPPULLUP_YMIN defined?

[marcio-ao]

@th33xitus : What "Configuration.h" file are you using? Is it the default, or a customized one?

[th33xitus]

````
// Enable pullup for all endstops to prevent a floating state

define ENDSTOPPULLUPS

if DISABLED(ENDSTOPPULLUPS)

// Disable ENDSTOPPULLUPS to set pullups individually
//#define ENDSTOPPULLUP_XMAX
//#define ENDSTOPPULLUP_YMAX
//#define ENDSTOPPULLUP_ZMAX
//#define ENDSTOPPULLUP_XMIN
//#define ENDSTOPPULLUP_YMIN
//#define ENDSTOPPULLUP_ZMIN
//#define ENDSTOPPULLUP_ZMIN_PROBE

endif

````
That's the configuration i use for a very long time and i compiled the newest bugfix with this configuration as well. It's based on the default configuration.h file. I only adjust the settings and parameters i need.
Do you wan't me to try and change any of those settings?

[teemuatlut]

What's your motherboard and driver setup like?

I'm not sure if this is endstop or sensorless homing related. For some reason the response from the X and Y drivers was faulty and thus Marlin got bad information and reacted accordingly.

[th33xitus]

@teemuatlut
Motherboard: RAMPS 1.4 EFB
Driver Setup: Watterott TMC2130 HW SPI on all axes.

Do you need more information?

[marcio-ao]

@th33xitus : Those pull-ups look correct to me.

I agree with teemuatlut, I think the first step is to see if this is sensorless homing related. There were probably other changes made to Marlin and we need to make sure this is related to sensorless homing.

Maybe start by commenting out #define SENSORLESS_HOMING in Configuration_adv.h and see if at least the printer starts up without the halt.

[teemuatlut]

No that was exactly what I wanted to know.

If you think the drivers would be acting without a problem and this is just a false positive, you can disable MONITOR_DRIVER_STATUS and Marlin will no longer kill itself.

[marcio-ao]

@teemuatlut: Here's a thought. The schematics for his steppers appears to be this:

https://github.com/watterott/SilentStepStick/blob/master/hardware/SilentStepStick-TMC2130_v11.pdf

Notice that this puts the DIAG0 and DIAG1 inputs on the lower right of the breakout board, next to VRef. If this is the case, then it looks like maybe DIAG0 and DIAG1 would not be mated to his RAMPS board. Does Marlin rely on the DIAG1 and DIAG0 lines in order to detect errors, or is it just polling via SPI?

[th33xitus]

@marcio-ao I tried and deactivated sensorless homing but the driver error still occured.

@teemuatlut I then disabled MONITOR_DRIVER_STATUS and flashed again and now sensorless homing isn't working anymore. I had the homing sensitivity sat to 26 the whole time, i decreased it to 8 and then even to 0 but both times the motor doesn't stop spinning and i have to kill the printer manually.

[marcio-ao]

@th33xitus: This may be a bit of an advanced question, but are you able to see if the DIAG0 and DIAG1 pins in your board are actually going anywhere? Look at the second page on this PDF, it will show you the position of DIAG0 and DIAG1. I guess I am curious whether there is a mating connector on your RAMPS board.

If this is not something you can see easily (i.e. you would have to take apart your printer), then maybe we can assume these outputs were correct since you did say that sensorless homing was working before.

[teemuatlut]

A standard RAMPS board does not have mating connectors for these pins. The user is instructed to solder a pin upright to the DIAG1 connector and attach a wire to a desired endstop pin.

MONITOR_DRIVER_STATUS polls the drivers and determines if there's a problem from the response. It would be more efficient to react to a pin change and only communicate then, but I couldn't assume the user would even be using stallGuard homing and so there might not be a connecting wire in place.

~I'm now checking if the homing routines were changed accordingly when the changes were made...~
EDIT: No need for that it seems...

[th33xitus]

@marcio-ao

A standard RAMPS board does not have mating connectors for these pins. The user is instructed to solder a pin upright to the DIAG1 connector and attach a wire to a desired endstop pin.

Correct, and this is the only thing i did. I only have the DIAG1 Pin connected via a jumpercable to the signal pin of the corresponding endstop which worked flawlessly all the time before.

[marcio-ao]

@teemuatlut : Ahhh. Makes sense. That clears it up for me. Thank you.

[marcio-ao]

@teemuatlut : I suppose I could add a "Configuration_adv.h" option to enable the old behavior of having DIAG1 active high. Although I don't think that should be necessary.

[marcio-ao]

@th33xitus: Did you get your Marlin code using "git"? If so, make a copy of your Marlin source tree to another directory, then change into it and type:

git revert 53757444c5285b85ca186f88a2e5a5d619e2e875

Then, X_MIN_ENDSTOP_INVERTING and Y_MIN_ENDSTOP_INVERTING back to "false", recompile and see if it makes a difference.

[th33xitus]

No, i always download the zip file. So i have no real chance to revert back to a earlier commit right? I think i need to get into git anytime soon ^^

[marcio-ao]

@th33xitus: Well, do you think you can read a diff well enough to manually undo the changes?

https://github.com/MarlinFirmware/Marlin/commit/53757444c5285b85ca186f88a2e5a5d619e2e875

The stuff in red was in the previous version, and the stuff in green got added to the next version. So to undo the commit, replace the stuff in green with the stuff in red. It's not very many changes. Just a one-liner, plus removing the sanity check.

[th33xitus]

Okay i just did the manual changes and it compiled fine.
I did two testruns. One testrun was compiled with MONITOR_DRIVER_STATUS enabled and i instantly got the same error as mentioned in entry-post.

Then i disabled MONITOR_DRIVER_STATUS and compiled and flashed again, the printer booted just fine but now the endstops are triggered immediately.

I compiled with the following endstop-settings:
````
// Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup).

define X_MIN_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.

define Y_MIN_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.

define Z_MIN_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.

define X_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.

define Y_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.

define Z_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.

define Z_MIN_PROBE_ENDSTOP_INVERTING true // set to true to invert the logic of the probe.

````
M119 throws me all 3 endstops as triggered without even being able to home them properly.

EDIT:
I just tried and disabled the inverting
````
// Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup).

define X_MIN_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.

define Y_MIN_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.

define Z_MIN_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.

define X_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.

define Y_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.

define Z_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.

define Z_MIN_PROBE_ENDSTOP_INVERTING true // set to true to invert the logic of the probe.

````
M119 shows me X and Y as open, Z as triggered (Z is NOT triggered in real).
In this case i was able to home X and Y but sensorless homing didn't trigered again and i had to kill the printer manually again to prevent the motors from spinning

[Ludy87]

My problem is very similar to the ENDSTOPS.

https://github.com/MarlinFirmware/Marlin/issues/10359

[marcio-ao]

@th33xitus : If you un-did the changes in commit 5375744 and it still is giving the error, then I suspect it was not the commit regarding the SENSORLESS_HOMING that broke things. Something else is wrong, we just haven't figure out what yet.

[marcio-ao]

@th33xitus : You did add back the line that said "st.diag1_active_high(1); // For sensorless homing", right?

[th33xitus]

Yes, i added the st.diag1_active_high(1); // For sensorless homing back into line 190 and replaced the "big block" with the "small block" in the SanityCheck.h file.
I edited both files the way you told me.

[marcio-ao]

@th33xitus : Thanks for verifying that. I think the conclusion now is that the cause for the problems you are seeing remain unknown. I don't think it was the change of the polarity of the diag pin. The sanitycheck error people are seeing is probably leading folks to believe that that particular change was the problem, but I think we have shown that it isn't.

[teemuatlut]

I just uploaded a rebased (#8669dba) bugfix-2.0.x to my RAMPS based printer (3x TMC2130 + 2x TMC2208) and everything seemed fine. No driver errors on startup and sensorless homing worked out of the box after I swapped the logic as instructed by the sanity check.

[th33xitus]

@teemuatlut Okay so you say i should give the #8669dba a try?
I will configure it for my RAMPS-Setup and then will report.

But then still the question whats diffrent there. Why is the bugfix-2.0.x working and the bugfix-1.x.x not? I thought you guys keep them on the same level as far as possible?

[teemuatlut]

It should be and I don't know any differences that would cause your problems. Personally I've moved to using the v2 branches only and all I'm saying is that while doing a normal maintenance update for my own printer, I wasn't able to reproduce your problem.
Updating the branch in your case may or may not solve anything, but it's something you can try.
You could also try disabling SD support as that could potentially clash with the SPI communication.
Or you can try software SPI if that works better in your case.

[th33xitus]

Okay this will take longer as expected since i have problems with compiling the 2.0.x. My Arduino IDE gives me an compiling error, that the fielpath and/or extension is too long. Pretty funny since i ALWAYS compile the firmwares located on my desktop. Never get an issue there with the 1.x.x firmwares.

Well... if someone knows a solution for this: pls tell me.
Otherwise: i will report back as soon as i managed to compile it :(

[teemuatlut]

Use IDE beta version 1.9.0 or edit your %localappdata%/Arduino15/preferences.txt and add/edit this: build.path=C:\arduino_builds

[th33xitus]

@teemuatlut Thank you! Using Arduino IDE 1.9.0 Beta actually did the trick.

I was able to compile and flash successfully. And it works fine.
Sensorless homing works again, no false positives, no early endtop triggers and most important no driver errors!

Only my stepper motors are now buzzing like hell while being active, which wasn't the case before. Any idea on how to solve this?

[teemuatlut]

What's your M122 output?
Actually I'd have to see all the raw registers but that's in another development branch. Perhaps it's time to update that one as well.

[th33xitus]

That's my output. Do you see any issues there?
Send: M122 Recv: X Y Z E0 E1 Recv: Enabled false false false false false Recv: Set current 638 638 638 638 638 Recv: RMS current 611 611 611 611 611 Recv: MAX current 862 862 862 862 862 Recv: Run current 19/31 19/31 19/31 19/31 19/31 Recv: Hold current 9/31 9/31 9/31 9/31 9/31 Recv: CS actual 9/31 9/31 9/31 9/31 9/31 Recv: PWM scale 2 2 58 2 62 Recv: vsense 1=.18 1=.18 1=.18 1=.18 1=.18 Recv: stealthChop true true true true true Recv: msteps 16 16 16 16 16 Recv: tstep 1048575 1048575 1048575 1048575 1048575 Recv: pwm Recv: threshold 4294967295 4294967295 395 277 1664 Recv: [mm/s] 0.00 0.00 5.00 29.92 4.98 Recv: OT prewarn false false false false false Recv: OT prewarn has Recv: been triggered false false false false false Recv: off time 5 5 5 5 5 Recv: blank time 24 24 24 24 24 Recv: hysteresis Recv: -end 2 2 2 2 2 Recv: -start 3 3 3 3 3 Recv: Stallguard thrs 26 26 0 0 0 Recv: DRVSTATUS X Y Z E0 E1 Recv: stallguard X X Recv: sg_result 895 464 0 0 0 Recv: fsactive Recv: stst X X X X X Recv: olb Recv: ola Recv: s2gb Recv: s2ga Recv: otpw Recv: ot Recv: Driver registers: X = 0x81:09:03:7F Recv: Y = 0x81:09:01:D0 Recv: Z = 0x80:09:00:00 Recv: E0 = 0x80:09:00:00 Recv: E1 = 0x80:09:00:00 Recv: Recv: Recv: ok

[teemuatlut]

Not any glaring ones as I suspected but that doesn't actually even show the register I would need to see.
I'll try to get my debugging branch rebased but in the mean time could you test if your physical movement reflect your G1 commands? Basically test how much your axis moves when you send G91 and G1 X10.

Edit: This is my debugging branch that allows you to read the raw register values with M122 V1.

[th33xitus]

I can confirm that my physical movements reflect my G1 commands.
Just put some squared paper on my heatbet, aligned my x-carriage with the lines on the paper and then send a G91 followed by several G1 X10 commands and i checked after each command.
My carriage moved exactly 10mm (two squares).

[th33xitus]

@teemuatlut Okay here you go, the verbose output of M122 i got with your debugging branch:
Send: M122 V1 Recv: X Y Z E0 E1 Recv: GCONF 0x00:00:00:04 0x00:00:00:04 0x00:00:00:04 0x00:00:00:04 0x00:00:00:04 Recv: IHOLD_IRUN 0x00:00:13:09 0x00:00:13:09 0x00:00:13:09 0x00:00:13:09 0x00:00:13:09 Recv: GSTAT 0x00:00:00:00 0x00:00:00:00 0x00:00:00:00 0x00:00:00:00 0x00:00:00:00 Recv: IOIN 0x11:00:00:FA 0x11:00:00:F8 0x11:00:00:7A 0x11:00:00:78 0x11:00:00:7A Recv: TPOWERDOWN 0x00:00:00:80 0x00:00:00:80 0x00:00:00:80 0x00:00:00:80 0x00:00:00:80 Recv: TSTEP 0x00:0F:FF:FF 0x00:0F:FF:FF 0x00:0F:FF:FF 0x00:0F:FF:FF 0x00:0F:FF:FF Recv: TPWMTHRS 0xFF:FF:FF:FF 0xFF:FF:FF:FF 0x00:00:01:8B 0x00:00:01:15 0x00:00:06:80 Recv: TCOOLTHRS 0x00:00:00:00 0x00:00:00:00 0x00:00:00:00 0x00:00:00:00 0x00:00:00:00 Recv: THIGH 0x00:00:00:00 0x00:00:00:00 0x00:00:00:00 0x00:00:00:00 0x00:00:00:00 Recv: CHOPCONF 0x14:02:82:A5 0x14:02:82:A5 0x14:02:82:A5 0x14:02:82:A5 0x14:02:82:A5 Recv: COOLCONF 0x00:1A:00:00 0x00:1A:00:00 0x00:00:00:00 0x00:00:00:00 0x00:00:00:00 Recv: PWMCONF 0x00:05:05:FF 0x00:05:05:FF 0x00:05:05:FF 0x00:05:05:FF 0x00:05:05:FF Recv: PWM_SCALE 0x00:00:00:03 0x00:00:00:03 0x00:00:00:3C 0x00:00:00:03 0x00:00:00:3A Recv: DRV_STATUS 0x81:09:03:B9 0x81:09:01:D0 0x80:09:00:00 0x80:09:00:00 0x81:09:02:47 Recv: ok

[teemuatlut]

The registers look fine. Please do a full power cycle and see if that does anything.

[th33xitus]

Okay please explain me what do you mean with "full power cycle". I don't know what that means, im sorry.

[teemuatlut]

Power down the printer and even unplug it so that there's no more power provided. Neither 12V nor 5V.

[th33xitus]

Ohh okay gotcha.
I just unplugged it from the mains and plugged it back in, still got a horrible whining noise.
BUT, i then remembered that i forgot to send a M502 to my machine after flashing your debugging branch.
So i just send a M502 followed by a M500 and tried again and the whining is gone. It's just a silent rustle you can still hear while the steppers are active.
So i guess this problem is solved then. But im still wondering which parameters you can store in the EEPROM can cause such an issue??...

[teemuatlut]

The settings stored are driver current, homing sensitivity and hybrid threshold.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.