driver error TMC 2130

[ghost]

Hello,
i`m getting seemingly random "driver errors" with my tmc 2130.
The LCD only shows "driver error" and i cant really get a clue from the seriel out also.
I sometimes happes while printing but sometimes also while ideling.

My drivers are actively cooled and i`m using the latest 1.1.x bugfix

any help would be appreciated.
I'm thinking about just disabling the stop_on_error becuase i cant find any reason for this errors

X driver error detected:  
                X       Y  
 Enabled                true    true  
 Set current    1100    1100  
 RMS current    1049    1049  
 MAX current    1479    1479
 Run current    18/31   18/31
 Hold current   3/31    3/31
 CS actual              18/31   18/31
 PWM scale      112     132
 vsense         0=.325  0=.325
 stealthChop    true    true
 msteps         16      16
 tstep          389     202
 pwm
 threshold              0       0
 [mm/s]         -       -
 OT prewarn     false   false
 OT prewarn has
 been triggered false   false
 off time               5       5
 blank time     24      24
 hysterisis
 -end           2       2
 -start         3       3
 Stallguard thrs        13      13
 DRVSTATUS      X       Y
 stallguard
 sg_result              0       0
 fsactive
 stst
 olb
 ola
 s2gb
 s2ga
 otpw
 ot
 Driver registers:      X = 0x00:12:00:00
        Y = 0x00:12:00:00
 Error:Printer halted. kill() called!
 [ERROR] Error:Printer halted. kill() called!

[teemuatlut]

I will need to change a few things to clear situations like these because I can't see anything wrong either. But for some reason the driver did report an error and Marlin reacted to it.

You can disable STOP_ON_ERROR. The main purpose for it is to save time and material on situations where there has been an error and the driver has shut itself down. Before this feature Marlin of course didn't know that a driver needs a reset and just kept printing thinking everything was fine.

[sh4jonny]

Do you use SD card ?

[mylife4aiurr]

I see this error when the printer is connected to usb power from computer or Octoprint but not connected to PSU power

[Bob-the-Kuhn]

Try putting a 10K pulldown on the MISO line. That solved TMC2130 problems on a couple of five TMC2130 systems that were using a daisy chained cable.

[hevilp]

It is the same on me?
Any news how to fix it? Many weeks it worked very good.

Log Output

< 23:00:36.357: N238738 G1 X180.470 Y80.700 E15.6409
> 23:00:36.407: ok
< 23:00:36.407: N238739 G1 X181.060 Y81.036 E15.6739
> 23:00:36.415: Y driver error detected:
> 23:00:36.418:   X Y E0
> 23:00:36.418: Enabled  true true true
> 23:00:36.419: Set current 800 800 500
> 23:00:36.422: RMS current 795 795 489
> 23:00:36.423: MAX current 1121 1121 689
> 23:00:36.425: Run current 25/31 25/31 15/31
> 23:00:36.426: Hold current 12/31 12/31 7/31
> 23:00:36.426: CS actual  25/31 25/31 15/31
> 23:00:36.429: PWM scale 53 82 29
> 23:00:36.430: vsense  1=.18 1=.18 1=.18
> 23:00:36.432: stealthChop true true true
> 23:00:36.432: msteps  16 16 16
> 23:00:36.433: tstep  265 2110 1617
> 23:00:36.433: pwm
> 23:00:36.436: threshold  98 98 95
> 23:00:36.436: [mm/s]  100.85 100.85 30.04
> 23:00:36.437: OT prewarn false false false
> 23:00:36.438: OT prewarn has
> 23:00:36.440: been triggered false false false
> 23:00:36.440: off time  5 5 5
> 23:00:36.441: blank time 24 24 24
> 23:00:36.441: hysterisis
> 23:00:36.442: -end  2 2 2
> 23:00:36.443: -start  3 3 3
> 23:00:36.444: Stallguard thrs 0 0 0
> 23:00:36.444: DRVSTATUS X Y E0
> 23:00:36.445: stallguard    
> 23:00:36.445: sg_result  0 0 0
> 23:00:36.448: fsactive    
> 23:00:36.448: stst    
> 23:00:36.448: olb    
> 23:00:36.449: ola    
> 23:00:36.449: s2gb    
> 23:00:36.449: s2ga    
> 23:00:36.450: otpw    
> 23:00:36.451: ot    
> 23:00:36.451: Driver registers:
> 23:00:36.452:  X = 0x00:19:00:00
> 23:00:36.452:  Y = 0x00:19:00:00
> 23:00:36.453:  E0 = 0x00:0F:00:00
> 23:00:36.456: Firmware was halted, trying to reconnect. Eventually running print is stopped.

[hevilp]

I figured out: There came with more weight on the X-axis. I changed from bowden to direct drive and those 200-300 gramms brings up the error.

TMC2130 can not handle a direct drive weight?

[hevilp]

And again, 2 got 2 fans to cool them and got bowden setup...

Log Output

< 11:37:00.405: N30137 G1 X245.500 Y138.679 E188.8947
> 11:37:00.450: X:52 |0b0|  Y:102 |0b0|  E:53 |0b0|  
> 11:37:00.845:  T:219.29 /218.00 B:70.33 /70.00 @:70 B@:0
> 11:37:00.950: X:52 |0b0|  Y:104 |0b0|  E:53 |0b0|  
> 11:37:01.450: X:54 |0b0|  Y:103 |0b0|  E:52 |0b0|  
> 11:37:01.844:  T:217.89 /218.00 B:70.39 /70.00 @:95 B@:0
> 11:37:01.949: X:54 |0b0|  Y:103 |0b0|  E:51 |0b0|  
> 11:37:02.406: echo:busy: processing
> 11:37:02.450: X:53 |0b0|  Y:103 |0b0|  E:52 |0b0|  
> 11:37:02.546: ok
< 11:37:02.547: M117 ETA 18:20:19 day 10
> 11:37:02.591: ok
< 11:37:02.592: N30138 G1 X225.541 Y158.637 E190.2677
< 11:37:02.592: N30139 G92 E0
> 11:37:02.615: ok
> 11:37:02.615: ok
< 11:37:02.616: N30140 G1 E-6.5000 F3600
< 11:37:02.616: N30141 G1 X206.998 Y176.539 F6000
> 11:37:02.667: ok
< 11:37:02.667: N30142 G1 E0.0000 F3600
< 11:37:02.667: N30143 G92 E0
> 11:37:02.845:  T:218.25 /218.00 B:70.44 /70.00 @:87 B@:0
> 11:37:02.950: X:50 |0b0|  Y:106 |0b0|  E:52 |0b0|  
> 11:37:03.450: X:51 |0b0|  Y:108 |0b0|  E:52 |0b0|  
> 11:37:03.844:  T:217.52 /218.00 B:70.30 /70.00 @:99 B@:0
> 11:37:03.949: X:52 |0b0|  Y:104 |0b0|  E:52 |0b0|  
> 11:37:04.053: X:225.54 Y:158.64 Z:2.97 E:0.00 Count X:18043 Y:12691 Z:2376
> 11:37:04.053: ok
> 11:37:04.058: ok
< 11:37:04.059: N30144 G1 X206.998 Y182.989 E0.3137 F2400
> 11:37:04.061: ok
> 11:37:04.065: ok
< 11:37:04.065: N30145 G1 X205.438 Y182.989 E0.3896
> 11:37:04.459: X driver error detected:
> 11:37:04.460: overtemperature
> 11:37:04.462: short to ground (coil A)
> 11:37:04.462:   X Y E0
> 11:37:04.463: Enabled  true true true
> 11:37:04.463: Set current 800 800 500
> 11:37:04.466: RMS current 795 795 489
> 11:37:04.468: MAX current 1121 1121 689
> 11:37:04.470: Run current 25/31 25/31 15/31
> 11:37:04.471: Hold current 12/31 12/31 7/31
> 11:37:04.472: CS actual  31/31 31/31 15/31
> 11:37:04.472: PWM scale 69 151 49
> 11:37:04.474: vsense  1=.18 0=.325 0=.325
> 11:37:04.475: stealthChop true true true
> 11:37:04.478: msteps  16 16 16
> 11:37:04.479: tstep  137 4294901888 1048575
> 11:37:04.479: pwm
> 11:37:04.479: threshold  98 98 263
> 11:37:04.482: [mm/s]  100.85 100.85 30.06
> 11:37:04.483: OT prewarn false false false
> 11:37:04.484: OT prewarn has
> 11:37:04.487: been triggered false false false
> 11:37:04.487: off time  5 5 5
> 11:37:04.488: blank time 24 24 24
> 11:37:04.489: hysterisis
> 11:37:04.489: -end  2 2 2
> 11:37:04.490: -start  3 3 3
> 11:37:04.491: Stallguard thrs 0 0 0
> 11:37:04.491: DRVSTATUS X Y E0
> 11:37:04.493: stallguard    
> 11:37:04.493: sg_result  0 0 0
> 11:37:04.493: fsactive    
> 11:37:04.495: stst    X
> 11:37:04.495: olb    
> 11:37:04.495: ola    
> 11:37:04.496: s2gb    
> 11:37:04.497: s2ga    
> 11:37:04.497: otpw    
> 11:37:04.497: ot    
> 11:37:04.498: Driver registers:
> 11:37:04.499:  X = 0x00:19:00:00
> 11:37:04.499:  Y = 0x00:19:00:00
> 11:37:04.501:  E0 = 0x80:0F:00:00
> 11:37:04.503: Firmware was halted, trying to reconnect. Eventually running print is stopped.

[teemuatlut]

https://github.com/teemuatlut/Marlin/tree/TMC_debugging_v2
https://github.com/teemuatlut/Marlin/tree/bf2_TMC_debug_update
Please try my branch with updated monitoring code.
It makes only one call to the driver to determine the error conditions. This should/could improve detecting valid error states.

[hevilp]

I'm running the Marlin 2.x.x. from friday and it is running flawless now about 15 hours. (previous was marlin 1.1.8), I will try your branch next days.

[hevilp]

Please see:
teemuatlut/TMC2130Stepper#35 (comment)

[dventu]

Do you mind sharing your marlin folder as Im having the same issue.

[JonnyLeRoy]

I removed the original post. I don't need a written record of that mistake. It turns out that it was a fault with the end user.
Thanks to all that helped me resolve this issue.
As it turns out MONITOR_DRIVER_STATUS is an incredible diagnostic tool. In the absence of a lab scope.

[teemuatlut]

TMC drivers cannot communicate with Marlin if they don't have 12V power.

[JonnyLeRoy]

How can isolate the fault?

[hevilp]

Just disable MONITOR_DRIVER_STATUS and try a long print.

[thinkyhead]

@teemuatlut — Is there some way we can check that a driver doesn't have any 12V power (in tmc_status, etc.) and output something like "---" for that driver? And/or can we check for 12V power being off to all the drivers and if AUTO_POWER_CONTROL is enabled, turn them on?

[teemuatlut]

When the drivers don't have power the failed communication is indistinguishable from a faulty wiring or bad configuration. There were some specifics on what makes the SPI response be all zeros versus all ones.

The Marlin power control features are the only ways we can know if the power is turned on.
If the user has enabled PS_DEFAULT_OFF or AUTO_POWER_CONTROL, then I think the best course of action would be to turn on the PSU on startup long enough for Marlin to configure all the drivers and test working communication. The written configurations should persist even if VMOT power is lost.
This would also simplify some things as power_on would no longer need to worry about TMC drivers at all.

This does not solve a setup where the user would first power the board from USB and then manually switch power on before starting a print, or if it is controlled by OctoPrint, but we could implement a quick M code to refresh the drivers and the code could be inserted into the start gcode section. This would also require us to gracefully handle a failed comms check on startup.

[JonnyLeRoy]

After some testing. It is clear to me. Configuring 5 pins at the same time is not the best method. I will add one pin at a time. And report my finding. too bad I cut up my harness in a bit of rage.
Thanks to all. For all you help.

Are there any pins that are not compatible with CS ?

[thinkyhead]

Are there any pins that are not compatible with CS

Any of the free digital pins should be fine.

[JonnyLeRoy]

I found this article on the 2130s when I was looking for a way to test one.
Is there a way to test the 2130s to know if this is your issue? I have had my 2130s on standby with USB power for 4 weeks.

Boards with USB Power Supply
Only applicable for SilentStepSticks with variable 3-5V logic voltage (VIO): If you use a control board with USB power supply (like Arduino + RAMPS) then always ensure that the motor supply voltage (VM) is present, when you connect the board via USB. Otherwise the TMC2xxx is not powered via the internal voltage regulator and a high current can flow into VIO or the IOs and this can damage the internal logic. As safety workaround you can disconnect the 5V signal in the USB cable, so that the board cannot be powered over USB.
https://learn.watterott.com/silentstepstick/faq/#boards-with-usb-power-supply

[unixb0y]

I'm not sure if this is the right place to ask, but since somebody mentioned the SD card as a possible cause of error:
My 2130's run great and everything and I do have a smartcontroller with SD card slot attached to the RAMPS as well by just swapping the female AUX-3 connector with one that has very long legs so they stick all the way through the LCD connector.
But the issue is: As soon as I plug in an SD card, I see a "driver error" message on the screen and the printer is halted.
I haven't checked / configured the SD connection prior to configuring my printer for TMC2130 so it's possible that some SD card settings are wrong and produce this issue somehow.
Any help is appreciated, thank you in advance!

[JonnyLeRoy]

unixb0y, I'm glad you asked.
I replaced the SmartController. And that fixed the same issue on my system.

[unixb0y]

@JonnyLeRoy thank you very much, I’ll try to borrow one to see if it’s the smart controller in my case as well!

[github-actions]

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.