TMC2130 driver error after update

[sh4jonny]

hi after a long time work with 2130 i update to last 2.0 branch 2.2.0 lib. and have a error. Other hardware is Arduino DUE and RAMPS4DUE. X Y with tmc2130. here is a Pronterface output:

echo:SD card ok
¬ы;Hючjыёс driver error detected:
        ¬ы;Hючjыёс  ;Hючjыёс
Enabled     false   false
Set current 825 825
RMS current 1436    1436
MAX current 2025    2025
Run current 25/31   25/31
Hold current    12/31   12/31
CS actual       0/31    0/31
PWM scale   7   96
vsense      0=.325  0=.325
stealthChop false   false
msteps      256 256
tstep       6   128
pwm
threshold       0   0
[mm/s]      -   -
OT prewarn  false   false
OT prewarn has
been triggered  false   false
off time        0   0
blank time  16  16
hysteresis
-end        -3  -1
-start      1   1
Stallguard thrs 0   0
DRVSTATUS   ¬ы;Hючjыёс  ;Hючjыёс
stallguard
sg_result       0   0
fsactive
stst
olb
ola
s2gb
s2ga
otpw
ot
Driver registers:   ¬ы;Hючjыёс = 0x00:00:00:00
    ;Hючjыёс = 0x00:00:00:0F
Error:Printer halted. kill() called!
[ERROR] Error:Printer halted. kill() called!

also i have pins debug output

>>> m43
SENDING:M43
echo:SD card ok
PIN: 00        RXD                                    Input  = 1
PIN: 01        TXD                                    Input  = 1
PIN: 02        <unused/unknown>                       Input  = 1
PIN: 03        X_MIN_PIN                              protected
PIN: 04        <unused/unknown>                       Input  = 1
PIN: 05        <unused/unknown>                       Input  = 1
PIN: 06        <unused/unknown>                       Input  = 1
PIN: 07        <unused/unknown>                       Input  = 1
PIN: 08        HEATER_BED_PIN                         protected
.              RAMPS_D8_PIN                           protected
PIN: 09        FAN_PIN                                protected
.              RAMPS_D9_PIN                           protected
PIN: 10        HEATER_0_PIN                           protected
.              RAMPS_D10_PIN                          protected
PIN: 11        E0_AUTO_FAN_PIN                        protected
PIN: 12        FAN1_PIN                               protected
PIN: 13        LED_PIN                                Input  = 1
PIN: 14        <unused/unknown>                       Input  = 1
PIN: 15        Y_MAX_PIN                              protected
PIN: 16        LCD_PINS_RS                            Output = 0
PIN: 17        LCD_PINS_ENABLE                        Output = 0
PIN: 18        Z_MIN_PIN                              protected
PIN: 19        <unused/unknown>                       Input  = 1
PIN: 20        <unused/unknown>                       Input  = 1
PIN: 21        <unused/unknown>                       Input  = 1
PIN: 22        <unused/unknown>                       Input  = 1
PIN: 23        LCD_PINS_D4                            Output = 0
PIN: 24        E0_ENABLE_PIN                          protected
PIN: 25        LCD_PINS_D5                            Input  = 1
PIN: 26        E0_STEP_PIN                            protected
PIN: 27        LCD_PINS_D6                            Input  = 1
PIN: 28        E0_DIR_PIN                             protected
PIN: 29        LCD_PINS_D7                            Input  = 1
PIN: 30        E1_ENABLE_PIN                          Output = 0
PIN: 31        BTN_EN1                                Input  = 1
PIN: 32        <unused/unknown>                       Input  = 1
PIN: 33        BTN_EN2                                Input  = 1
PIN: 34        E1_DIR_PIN                             Output = 0
PIN: 35        BTN_ENC                                Input  = 1
PIN: 36        E1_STEP_PIN                            Output = 0
PIN: 37        BEEPER_PIN                             Output = 0
PIN: 38        X_ENABLE_PIN                           protected
PIN: 39        <unused/unknown>                       Input  = 1
PIN: 40        Y_CS_PIN                               protected
PIN: 41        KILL_PIN                               Input  = 1
PIN: 42        X_CS_PIN                               protected
PIN: 43        <unused/unknown>                       Input  = 1
PIN: 44        <unused/unknown>                       Input  = 1
PIN: 45        <unused/unknown>                       Input  = 1
PIN: 46        Z_STEP_PIN                             protected
PIN: 47        <unused/unknown>                       Input  = 1
PIN: 48        Z_DIR_PIN                              protected
PIN: 49        SD_DETECT_PIN                          Input  = 0
PIN: 50        <unused/unknown>                       Input  = 1
PIN: 51        <unused/unknown>                       Input  = 1
PIN: 52        SDSS                                   Output = 1
.              SS_PIN                                 Output = 1
PIN: 53        <unused/unknown>                       Input  = 1
PIN: 54 (A 0)  X_STEP_PIN                             protected
PIN: 55 (A 1)  X_DIR_PIN                              protected
PIN: 56 (A 2)  Y_ENABLE_PIN                           protected
PIN: 57 (A 3)  <unused/unknown>   Analog in =   909   Input  = 1
PIN: 58 (A 4)  <unused/unknown>   Analog in =   851   Input  = 1
PIN: 59 (A 5)  TEMP_0_PIN                             protected
PIN: 60 (A 6)  Y_STEP_PIN                             protected
PIN: 61 (A 7)  Y_DIR_PIN                              protected
PIN: 62 (A 8)  Z_ENABLE_PIN                           protected
PIN: 63 (A 9)  <unused/unknown>   Analog in =   934   Input  = 1
PIN: 64 (A10)  <unused/unknown>   Analog in =   987   Input  = 1
PIN: 65 (A11)  TEMP_BED_PIN                           protected
PIN: 66        MAX6675_SS                             Input  = 1
PIN: 67        <unused/unknown>                       Input  = 1
PIN: 68        <unused/unknown>                       Input  = 1
PIN: 69        <unused/unknown>                       Input  = 1
PIN: 70        <unused/unknown>                       Input  = 1
PIN: 71        <unused/unknown>                       Input  = 1
PIN: 72        <unused/unknown>                       Input  = 1
PIN: 73        <unused/unknown>                       Input  = 1
PIN: 74        MISO_PIN                               Input  = 1
PIN: 75        MOSI_PIN                               Input  = 1
PIN: 76        SCK_PIN                                Input  = 1
PIN: 77        <unused/unknown>                       Input  = 0
PIN: 78        <unused/unknown>                       Input  = 1

maybe i lost some definitions when merge configs? thank you!

[thinkyhead]

Try this branch and see if it's any better: https://github.com/thinkyhead/Marlin/tree/bf2_eeprom_M913

[sh4jonny]

@thinkyhead i try it now and have same error ((((

[gunnarfreyr]

I notice when i run M122 , compared to yours, my RMS Current and Max current is much lower than yours. and probably the reason i feel the TMC2130 has very little torque ... Anybody know how to increse the RMS Current ?

[thinkyhead]

Anybody know how to increse the RMS Current ?

To set the motor current for X use M906 X<mA>.

[gunnarfreyr]

@thinkyhead Yeah i know how to set the current, i was just wondering why my RMS current and Max current are so much lower than his values since we have alomst the same current set ..

[thinkyhead]

@teemuatlut — I'm curious about the difference between the rms_current and setCurrent methods. I see that in tmc2208_init it calls st.rms_current(st.getCurrent(), ...) but in tmc2130_init it instead calls st.setCurrent(st.getCurrent(), ...). Is this just a question of the two driver models having different characteristics and running modes?

[teemuatlut]

When setting a new value rms_current is the newer version of setCurrent where just the arguments are in a different order. This was to allow the user to use rms_current(uint16_t, float) or even just rms_current(uint16_t) to set the current in a more simple way and not necessarily have to provide the hold_multiplier or r_sense values.

When reading they, or their counterparts, act a bit different. uint16_t getCurrent returns the value user asked to use. uint16_t rms_current reads from the driver and calculates the actual mA value.

[sh4jonny]

@thinkyhead @teemuatlut can you help me? i have strange symbols in drivers output and driver error on the screen (((

[teemuatlut]

What's your platform? There were a few changes to the way the extended axis codes were stored and it produced these strange symbols. This I believe was fixed already but I also saw it persist in some Due users output.

[sh4jonny]

@thinkyhead @teemuatlut so look. just now i eject my sdcard! and error is gone!!! i have 2 tmc2130 on hardware SPI and SDcard. Arduino DUE and HackedRAMPS. and all works with 2 month ago branch state.

[sh4jonny]

now i can 100% repeat this issue. when i insert sdcard i have drivers error. i eject it and all looks fine

[thinkyhead]

SPI bus contention?

[sh4jonny]

@thinkyhead yes HW SPI for drivers and SD card

[MikeInNs]

Hi, I am having the same issue, I am using a MKS Gen 1.4 with a 'RepRap Discount Full Graphic Smart Controller' and using the the latest 1.1.X Dev version (also happens with 1.1.8). I installed TMC 2130 drivers using SPI and using the free pins for the CS. Everything works but the SD card, it fails to initialize and when trying to insert a card it errors out with 'Driver Error'. Is this because of using HW SPI and should use software? Any help is appreciated!

[Bob-the-Kuhn]

Please be very specific on how this happens.

A copy of the host log from power up to driver error would be most useful. It would be nice to see logs both with the SD card in and out when powering up. Probably best to attach them as .TXT files so as to make it easier to do side by side comparisons.

I noticed the echo:SD card ok a couple of times in the above when it shouldn't be there. The M43 one is absolutely strange.

>>> m43
SENDING:M43
echo:SD card ok
PIN: 00        RXD   

[MikeInNs]

Hi Bob, Thanks for the reply. I attached both logs as you requested. I hope they are helpful. If you need more info please let me know. StartUp-WithSD.txt StartUp-NoSD.txt

[MikeInNs]

Just a quick update, it seems I got it working by disabling 'MONITOR_DRIVER_STATUS'. The interesting part is that the SD Card initializes successfully and works fine. For now I will leave this disabled although I don't know if there is still an issue and by disabling I am just ignoring the cause (I probably am...) Thanks!

[Bob-the-Kuhn]

@teemuatlut - does MONITOR_DRIVER_STATUS make use of an interrupt?

If yes that would explain why the SD card and TMC SPI transfers interfere with each other.

Another possibility is the SD card sets the SPI rate fairly high. Can the TMC chips handle 8MHz?

[Bob-the-Kuhn]

The TMC2130 can run the SPI at 4MHz max. Try enabling one of these: //#define SPI_SPEED SPI_HALF_SPEED // about 4MHz //#define SPI_SPEED SPI_QUARTER_SPEED // about 2 MHz

[teemuatlut]

No and no.

I don't know how they behave with a higher clock like 8MHz when the CS line is not active.

[Bob-the-Kuhn]

I expect that the SD card sets the SPI controller to 8MHz and then later the monitor goes to check but doesn't re-init the speed.

We either need to have the monitor function re-init the speed each time it's run or limit the SD card speed. Where is the TMC SPI speed set?

[teemuatlut]

https://github.com/teemuatlut/TMC2130Stepper/blob/master/src/source/TMC2130Stepper.cpp#L103

Does SD card init the mode and speed each time it tries communicating? The same way TMC2130 does there.

[Bob-the-Kuhn]

The SD card code only inits the SPI the first time a card is accessed. It inits it to mode 0 and 250K until the card reports it capabilities. After that it changes the speed to the configured value if the card can support it.

I see that the TMC2130 code inits it to 2M and mode 3.

Is mode 3 correct? Per TMC2130 DATASHEET (Rev. 1.09 / 2017-MAY-15) page 22 , "with the slave latching the data from SDI on the rising edge of SCK". That's mode 0. Maybe there's a newer data sheet out there. TMC2130_datasheet.pdf

If mode 0 is correct then we can add a check to limit the SD card speed to 2MHz when the TMC2130 is being used. Everyone will play nicely together.

[teemuatlut]

See datasheet p23 and the blue hint box.

Usually this SPI timing is referred to as SPI MODE 3.

[Bob-the-Kuhn]

If I read the following correctly, SPI mode 0 and SPI mode 3 are equivalent as to when the data is clocked in. That means the 0 vs. 3 is probably a don't care and the only culprit is the speed.

I'll start PRs to limit the SD card speed.

[Bob-the-Kuhn]

@MikeInNs - please test my proposed fix. Replace your Conditionals_LCD.h file and see if the SD card and MONITOR_DRIVER_STATUS work together.

Conditionals_LCD bugfix-1.1.x.zip Conditionals_LCD bugfix-2.0.x.zip

[MikeInNs]

@Bob-the-Kuhn, Thanks, will do! I am at work right now but I should have time this evening to test it out.

[MikeInNs]

@Bob-the-Kuhn, I just tried your change but I am afraid the same issue persists. I even tried 1/2 and 1/8 SPI speed but no change. SD stops initializing, when inserting the card it errors with 'Driver Error'. If you need more info or want me to test something else just let me know. And thanks for your help!

[Bob-the-Kuhn]

Means there's another problem besides the speed.

I was thinking for a while that, if the TMC code was running a software SPI using the same SCK, MOSI & MISO pins as the SD card's hardware SPI, it would kill the MONITOR. But that wouldn't explain why the SD card wasn't functional.

Keep the new conditionals file and try this change to line 103 in .piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper.cpp FROM SPI.beginTransaction(SPISettings(16000000/8, MSBFIRST, SPI_MODE3)); TO SPI.beginTransaction(SPISettings(16000000/8, MSBFIRST, SPI_MODE0));

If that doesn't do it then someone with the right hardware and a logic analyzer will need to troubleshoot it.

I

[Bob-the-Kuhn]

I don't have a functional TMC2130 to play with so I can't confirm it but ...

I downloaded a minimal config to a 2560 and, as soon as I plugged in the SD card, got a "X driver error detected:" message and the controller reset. It continued the error - reset loop as long as the SD card was inserted.

The problem was the X_CS_PIN was set to the same select pin as used by the SD card. When I changed pins_RAMPS.h so that X_CS_PIN wasn't assigned to pin 53 then the problem went away.

Try doing a M43 I to see if any of the TMC chip selects are shared with SDSS (or SS).

[Bob-the-Kuhn]

I was probably off in left field on that last comment.

I put a logic analyzer on my 2560 and found out that the TMC2130 is running a software SPI using different SCK & MOSI pins than the SD card.

[MikeInNs]

@Bob-the-Kuhn, I will try changing the SPI mode for the TMC2130. Like yesterday, I am at work now so it will have to wait till I get back. You mentioned Software SPI, the weird thing is (well I find it weird) when I try to run the TMC’s using software SPI I end up with the same issue.

I did check with M43 my pin outs and as far as I can see nothing is conflicting, I had to change the pins for the CS lines in the Ramps.h.

Currently I have it setup as follows: SPI: MOSI, MISO and SCK connect to the hardware SPI pins on the board. X-CS: D11 (Servo Pin) Y-CS: D6 (Servo Pin) Z-CS: D5 (Servo Pin) EO-CS: D4 (Servo Pin) E1-CS (acting as Z2): D40 X-Diag1: XMin Endstop (D3) Y-Diag1: YMin Endstop (D14)

[Bob-the-Kuhn]

I have a TMC2130 connected to my DUE (RAMPS_FD_V1) via the softSPI. All is working as expected.

Please ZIP & post the following files: Configuration.h, Configuration_adv.h and pins_YOUR-BOARD.h

[MikeInNs]

@Bob-the-Kuhn, thanks for willing to take a look a this, appreciate all the time you are putting into this. Attached are the files you requested, this is the working config, the only difference is the "MONITOR_DRIVER_STATUS" being switched off. (turning this on brings back the Driver Error)

Marlin 1.1.X-TMC2130-Config-Mike.zip

[Bob-the-Kuhn]

I thought that I had a functioning TMC2130 but the chip select are not going active. I've tried both the hardware SPI and TMC software SPI. I've put the #define X_CS_PIN 38 in pins_RAMPS_FD_V1 and in Configuration_adv.h.

I've enabled the following in Configuration_adv.h:

#define HAVE_TMC2130
#if ENABLED(HAVE_TMC2130)  // Choose your axes here. This is mandatory!
  #define X_IS_TMC2130
...
#define X_CS_PIN          38

I there something else I need to enable?

[MikeInNs]

As far as I know that should be it, maybe try another pin?

[thinkyhead]

My sense from looking at the SD-related files is that the library (at the time Marlin adopted it) assumes that the SD card's SPI bus won't be shared with a device that needs different speeds and/or modes. Possibly the newer SDFat library is more savvy about this. ("Key changes: The SPI divisor has been replaced by SPISettings in the begin() call.")

The reason we haven't migrated is that the Marlin version includes some needed customizations (e.g., long filenames).

Since the SD code is getting a bit old, it may be worthwhile to do a minor overhaul to the SD libs, host them as proper libraries under the MarlinFirmware organization, and migrate to those as part of the 2.0.0 or 2.1.0 milestone. We should also evaluate alternative SD libraries, in case there happen to be any modern variants with cleaner interfaces and more flexibility.

[Bob-the-Kuhn]

I finally figured out my TMC2130 problem. I tried to use an endstop pin as the X_CS_PIN but on a RAMPS FD V1 board they are input only because of the board's design.

On the DUE for sure, the TMC2130 software only initializes the hardware SPI controller on the very first access. The result is the speed & mode are set by the last device to init the controller. In every case it's the SD card. The net result is the TMC2130 SPI accesses are changed from mode 3 to mode 0 soon after reset and run at the last speed set by the SD card code.

I did finally figure out how to limit the SD card's speed. The logic has to go into a different file. Please see if this fixes the monitor problem. Conditionals_post 2.0.x.zip

There is something strange going on with the SD card logic. It tries to access the card on startup even though the card isn't inserted and sometimes it leaves the SD select active all the time.

Something to look at tomorrow.

[teemuatlut]

the TMC2130 software only initializes the hardware SPI controller on the very first access

It should init the SPI controller at the start of each communication attempt.

[Bob-the-Kuhn]

SPI.beginTransaction() isn't implemented on the DUE & LPC1768.

[teemuatlut]

Damn. Maybe we should try to agree on a common implementation when compiling for the Due platforms.

[teemuatlut]

Apparently there are some differences in the SPI class interface and implementation between AVR and SAM. If I don't provide a SS pin for the beginTransaction or begin methods, it'll use the default SS pin to match settings. There are no pin arguments available for the AVR SPI.

Not sure if this will fix the issue but I'll be making the change for Due anyway.

[Bob-the-Kuhn]

I don't see a reason to change the TMC2130 software with the possible exception of the mode. As best I can tell the TMC2130 is happy with DUE & LPC1768 which puts the SPI into mode 0.

The mode change is a "nice to do" item as far as I'm concerned. I don't see any functional issues either way.

The Marlin software assumes the SPI users control the SPI slave select. I don't think there is such a thing as a default SPI select pin. All the pins files have one defined for the SD card on the LCD. At least on DUE the TMC2130 object is created with a chip select.

Eventually DUE & LPC1768 will support SPI.beginTransaction().

[MikeInNs]

@Bob-the-Kuhn, I tried the Conditionals_Post.h you modified but I am afraid I am still experiencing the same issue.

[Bob-the-Kuhn]

@sh4jonny - please try the Conditionals_post 2.0.x.zip posted above and see if that fixes your DUE system issues. It did on mine.

[Bob-the-Kuhn]

@MikeInNs - I have your config in a 2560/RAMPS system & I can't duplicate your problem. I have five TMC2130s in it.

I can definitely get the kill message when I want to. Got plenty of them when learning how to setup my TMC2130 system.

I'm using a daisy chained cable. My system wouldn't run reliably until I put a 10K pull down on the very end of my cable. Before that I'd get a kill message from 2-120 seconds after reset.

Having the SD card inserted or not did not matter.

Maybe adding a pulldown will affect how your system works.

---

What an ugly pile of spaghetti!

Are there controllers/shields dedicated to the TMC2130 (doesn't need external cables)?

[Bob-the-Kuhn]

The above was using bugfix-1.1.x and PlatformIO. It compiles with Arduino 1.8.5 but it won't upload. I'm getting to hate Arduino.

[MikeInNs]

@Bob-the-Kuhn, thanks so much for trouble shooting this! So yes, this means I might have a hardware issue with my board. My SPI lines are daisy chained as well, do you mind explaining where you used the pulldown resistor?

The only thing I can think off is that the MKS Gen V1.4 has pullup resistors on the endstops which I use with the Diag1 pins (X/Y) (Don't think the Ramps has these) So I can try different pins for these.

And yes, it's an ugly pile of spaghetti for sure, tried to keep the cables as short as possible and the daisy chaining helped a little. I haven't heard of any existing boards with the 2130's integrated using SPI, however a new board is going to be released that will have this, it's called 'The Revolve'

Thanks again Bob!

[teemuatlut]

I haven't heard of any existing boards with the 2130's integrated using SPI

Einsy, Archim2, TRAMS (TMC5130) and probably a bunch of others that are currently in development. So while not many, there are still some and likely more to come.

[Bob-the-Kuhn]

I put the pull down on the MISO line on the very last connector in the daisy chain. My chain has more than five TMC2130 connectors on it so it was easy for me to cobble it up.