[BUG] [bugfix-2.0.x] TMC5160 SD card unmounts and encoder 'clicks' itself

[klcjr89]

Description

I was originally running genuine Watterott TMC2130 drivers in SPI mode on my Azteeg x5 mini v3 controller board, with the SDO, SCK, and SDI pins for the drivers wired to the SD card breakout pins on the board. I had no issues at that point at all. The CS pins for each driver are defined in my pins file (attached below) for the board.

I then bought genuine Watterott TMC5160 drivers and installed them. There are no issues with printing, however, with the USB cord plugged into my computer to the board, the SD card will randomly mount and unmount, which didn't happen with the TMC2130s.

In addition to this, the LCD screen/encoder on my Ender-3 (the printer this is installed on) will randomly enter a menu by itself and also return to the main menu by itself, as if I were physically pressing on the encoder click button. This issue happens with and without the controller board being plugged into the computer via USB, as I was trying to rule things out. This didn't happen with the TMC2130s either.

I am unsure if there were code changes in the past two weeks to the main branch that would've caused this.

I verified it isn't a ground loop problem.

Steps to Reproduce

Physically swapped genuine TMC2130 drivers in SPI mode to genuine TMC5160 drivers in SPI mode.

Expected behavior:

SD card should not mount and unmount on computer by itself.

LCD screen should not enter menus by itself.

Actual behavior:

SD card mounts and unmounts randomly with controller board plugged into the computer via USB.

LCD screen randomly clicks a menu item by itself and returns to the info screen by itself, as if I were physically pressing the button.

I am tagging @teemuatlut to see if he can help.

Thank you!

My config files: ConfigFiles.zip

[gloomyandy]

What current do you have defined for your steppers? Are you sure your power supply can support it? This sounds a lot like some sort of power issue (or possibly noise being injected in some form). Is your heated bed powered from the same supply? If so try creating a gcode file that has the heated bed not heating (and if you can the nozzle also not heated) and try running that, do you still get crazy things happening (not having the bed/nozzle heated will reduce the current required considerably).

What happens if you switch back to your TMC2130 drivers with the same version of Marlin? Doing this would help eliminate any recent code changes.

[klcjr89]

Heated bed is powered from mains (silicone Keenovo), and the power supply is more than capable of handling the power the printer draws; it's genuine Meanwell LRS series.

I'm using 1200ma for X, Y, and Z steppers, and 300ma for my extruder. All stealthchop (I have linear advanced disabled). The 5160 stepsticks are supposed to be much better drivers than the 2130s.

I could definitely switch back to the 2130s just for testing purposes.

[gloomyandy]

You should try the old drivers to confirm it is not a recent change. Does reducing the current make any difference to what happens? What control board are you using?

[klcjr89]

If I reduce the current, that will mean I lose steps. I spent a week tuning accelerations and current for the printing I do.

The original post says I'm using an Azteeg x5 mini v3.

[gloomyandy]

Well it is your choice but if you want to get to the bottom of what is going on you need to experiment a little. It could be that there is some sort of noise or perhaps voltage drop on the board caused by the stepper drivers. The sort of problems you are seeing really do not sound like a firmware issue. How frequently are these random menu/sd card mount/dismount events happening?

But probably the first step is to see if you can go back to a working setup with the other stepper drivers.

[klcjr89]

It just didn't make sense to me as the 5160s are the flagship stepper driver now. I am not sure what part of the code to look at to see how it differs from the 2130.

[gloomyandy]

As I said above this sounds much more like an electrical noise problem then any sort of firmware issue. But who knows. Also remember that these stepper drivers are very new, there may be issues that have not come to light yet with them.

At the moment you have lots of changes between a working system and one that does not work. So to try and work out what is wrong you probably need to step back. The first stage is to get a working system. Then make one change at a time.

[klcjr89]

I just reduced the driver currents by 200ma for the XYZ axes, so that saves 600ma, and that didn't eliminate the issues I posted about.

As far as how often the screen enters a menu by itself, it seems to occur frequently; at least once, sometimes two or three times in one minute.

[klcjr89]

I just reinstalled the 2130s and can confirm that both the mounting/unmounting of the SD card randomly and LCD bug have disappeared.

[klcjr89]

Looking at the code in the file StepperIndirection.cpp, the code is different between the 2130 and 5160. I wonder if the issue lies there.

TMC2130

template<char AXIS_LETTER, char DRIVER_ID>
  void tmc_init(TMCMarlin<TMC2130Stepper, AXIS_LETTER, DRIVER_ID> &st, const uint16_t mA, const uint16_t microsteps, const uint32_t thrs, const float spmm, const bool stealth) {
    st.begin();

    CHOPCONF_t chopconf{0};
    chopconf.tbl = 1;
    chopconf.toff = chopper_timing.toff;
    chopconf.intpol = INTERPOLATE;
    chopconf.hend = chopper_timing.hend + 3;
    chopconf.hstrt = chopper_timing.hstrt - 1;
    st.CHOPCONF(chopconf.sr);

    st.rms_current(mA, HOLD_MULTIPLIER);
    st.microsteps(microsteps);
    st.iholddelay(10);
    st.TPOWERDOWN(128); // ~2s until driver lowers to hold current

    st.en_pwm_mode(stealth);
    st.stored.stealthChop_enabled = stealth;

    PWMCONF_t pwmconf{0};
    pwmconf.pwm_freq = 0b01; // f_pwm = 2/683 f_clk
    pwmconf.pwm_autoscale = true;
    pwmconf.pwm_grad = 5;
    pwmconf.pwm_ampl = 180;
    st.PWMCONF(pwmconf.sr);

    #if ENABLED(HYBRID_THRESHOLD)
      st.TPWMTHRS(12650000UL*microsteps/(256*thrs*spmm));
    #else
      UNUSED(thrs);
      UNUSED(spmm);
    #endif

    st.GSTAT(); // Clear GSTAT
  }
#endif

TMC5160

template<char AXIS_LETTER, char DRIVER_ID>
  void tmc_init(TMCMarlin<TMC5160Stepper, AXIS_LETTER, DRIVER_ID> &st, const uint16_t mA, const uint16_t microsteps, const uint32_t thrs, const float spmm, const bool stealth) {
    st.begin();

    int8_t timings[] = CHOPPER_TIMING; // Default 4, -2, 1

    CHOPCONF_t chopconf{0};
    chopconf.tbl = 1;
    chopconf.toff = timings[0];
    chopconf.intpol = INTERPOLATE;
    chopconf.hend = timings[1] + 3;
    chopconf.hstrt = timings[2] - 1;
    st.CHOPCONF(chopconf.sr);

    st.rms_current(mA, HOLD_MULTIPLIER);
    st.microsteps(microsteps);
    st.iholddelay(10);
    st.TPOWERDOWN(128); // ~2s until driver lowers to hold current

    #if ENABLED(ADAPTIVE_CURRENT)
      COOLCONF_t coolconf{0};
      coolconf.semin = INCREASE_CURRENT_THRS;
      coolconf.semax = REDUCE_CURRENT_THRS;
      st.COOLCONF(coolconf.sr);
    #endif

    st.en_pwm_mode(stealth);

    PWMCONF_t pwmconf{0};
    pwmconf.pwm_freq = 0b01; // f_pwm = 2/683 f_clk
    pwmconf.pwm_autoscale = true;
    pwmconf.pwm_grad = 5;
    pwmconf.pwm_ampl = 180;
    st.PWMCONF(pwmconf.sr);

    #if ENABLED(HYBRID_THRESHOLD)
      st.TPWMTHRS(12650000UL*microsteps/(256*thrs*spmm));
    #else
      UNUSED(thrs);
      UNUSED(spmm);
    #endif
    st.GSTAT(); // Clear GSTAT
  }
#endif

[kAdonis]

The TMC5160 are not made for low currents, Trinamic recommends not going below 1/4 of the maximum current, which is about 750mA for the Watterott drivers 1200mA are fine, but 300mA for E could be a problem, but I dont know if that is related to your issue I am using TMC5160 for X/Y on my coreXY with no problems You could try TMC5160 for X,Y and Z and TMC2130 for E

[klcjr89]

@kAdonis The 5160 has been working on my E0 perfectly fine with 300ma.

I also changed the value of the sense resistor in Marlin to 0.075 (the value of the Watterott 5160), but I don't think that's working properly either. Did you change the value @kAdonis? The default is 0.11 in Marlin, but that isn't correct for the Watterott 5160 stepsticks.

I just put the 5160s back in and the problems have returned.

The 2130s seem less sensitive to noise if that is the issue at hand.

[kAdonis]

I have different TMC5160 drivers and made my own adapter board, I soldered 0.22Ω sense resistors on my drivers to have better performance with my motors The Watterott drivers are using 0.075Ω sense resistors, thats right and the value is used in the stepper library to determine the current

The 5160 has been working on my E0 perfectly fine with 300ma.

It's working, yes but the mikrostep resolution is reduced, and the change from run to hold current is much faster. So i'm curious what happens if you just use a 2130 for E and keep the 5160 for the other axes

[klcjr89]

I wanted to wait for the 5161 stepstick, but Watterott assured me the 5160 stepstick is better (and runs cooler) as it has a lower RDSon, so I bought the 5160s.

I'm using 1/8 stepping interpolated to 256. The steps per mm is 1380 for my Zesty Nimble extruder.

I also have specified CHOPPER_DEFAULT_24V for the chopper timing variable.

[kAdonis]

They are great drivers, powerfull and dont need cooling. I never tried them with low currents

[klcjr89]

I have had less screen glitches after reinstalling them and no SD card unmounts yet, so would it be wise to wrap the SDO, SDI, and SCK wires with aluminum tape?

[kAdonis]

I dont know about the aluminium tape, I dont use shielded cables but I'm using SW SPI

[klcjr89]

Is it bad that I'm using hardware SPI by having the wires connected to the SD card slot pins?

[kAdonis]

Is it bad that I'm using hardware SPI by having the wires connected to the SD card slot pins?

It was working with your TMC2130, so I would expect it to work with the 5160 But as Gloomyandy wrote, make one change at a time

[klcjr89]

The only change I have made is to the drivers. (2130 to 5160 conversion).

[gloomyandy]

So what were the current settings on your drivers with TMC2130s installed? I suspect that you have a big jump in current flowing through a board that was probably not designed with that in mind.

I would go back to a working configuration then do the following.... Add one 5160 as say X if it works, switch it with another 5160 until you have tested each module in turn and established that it is not just a single one causing the glitching. Then put the 2130 back in X and try a 5160 in Y, if that is OK but the 2130 back in Y and try the 5160 in Z carry on until you know that you can use a 5160 in each socket with no problem. Then try with X and Y with 5160, then X, Y and Z. Basically you are trying to identify if there is any particular setup that seems to cause the problem. If with say 3 5160s you start seeing the problem try turning the current way down so that the total current is less than it was with 2 5160s and try again. Basically you need to narrow down what it is that is causing the problem, yes it is tedious, but unfortunately you are paying the price for being one of the first people to use this sort of configuration, very few people will have a setup the same as yours and so you have to do all of the work.

[7eggert]

This might also be due to the SPI interface. I looked at the data sheet and found this:

(Assuming the common form factor also found on RAMPS boards:) The TMC5160 has a CLK pin where TMC2130s have a NC pin. On my mainboard, this pin would be pulled high (for most drivers correctly) or connected to the neighboring pin (in this case SDO).

The datasheet say: "CLK input. Tie to GND using short wire for internal clock or supply external clock. Internal clock-fail over circuit protects against loss of external clock signal."

I'd re-solder that pin to the upside (heat and press using not-your-finger), then apply a GND signal by a resistor.

Important: 1) First try things that will not destroy your hardware. 2) You'll do this on your own risk 3) First try this with one module

If this works, I'd remove the pin and solder a resistor to a GND pin in it's place.

[klcjr89]

@7eggert That isn't the issue. The CLK pad is jumpered to GND as per Watterott's recommendation.

[kAdonis]

@klcjr89 I checked the Azteeg X5 mini v3 Diptrace design files, 7eggert is right, the pin is connected to the neighboring SDO pin, not to a jumper https://reprap.org/wiki/Azteeg_X5_mini

[klcjr89]

@kAdonis Maybe I am not explaining clearly, but there is no pin soldered in the pad for CLK on the 5160 driver board; it is jumpered to GND and doesn't mate with the female socket on the controller board.

[klcjr89]

[kAdonis]

Ah, great!

[comps]

It's a far shot, but just for the sake of elimination - make sure MISO is pulled up/down (I use 10K) and not left floating between slave switches.

[klcjr89]

@comps I'm not sure I follow. I know about floating pins being bad and using pull ups/downs, but why would this be needed if the 2130s didn't need them?

[klcjr89]

I am marking this closed as it doesn't seem to be a firmware problem.

[teemuatlut]

Be sure to report back and document how you solved your issue. It may later help some other user.

[klcjr89]

@teemuatlut Did you see the code snippet I posted that shows the difference between 2130 and 5160?

[teemuatlut]

Yes, the differences are a slightly different way to initiate chopper timing parameters, a missing init of the stored value for stealthChop and a feature that hasn't been implemented yet and so doesn't get compiled in. All that is likely due to a rebase mishap that I missed but it is not something that would cause your issues.

[kAdonis]

According to the Azteeg X5 mini v3 Diptrace design files, MISO and MOSI are pulled up with 10k near the header. Watterott write in their FAQ:

What is the difference between TMC5160 and TMC2130 SilentStepSticks?

TMC5160 SilentStepSticks have no standalone mode and no internal pull-up resistor on the CS/SS pin.(...)

you may want to try a pull-up resistor on CS. My drivers dont have a pull-up on CS either but I am not using a shared SPI port like you

[klcjr89]

Does the 2130 have a pull up on CS? If not, what would the difference be between the 5160 to cause issues?

[kAdonis]

Does the 2130 have a pull up on CS?

Watterott says: Yes, they have an internal pullup

I am no expert, I might tell nonsense here. With CS (Chip select) floating the TMC5160s might send data to the SPI, at times they shouldn't do this, possible colliding with other data on the SPI-bus

I would try it, just because there is a difference between the drivers

[klcjr89]

@kAdonis The 5160 doesn't have a pull up? That seems like a design oversight.

[kAdonis]

Tell that Watterott

[klcjr89]

Do I modify the controller board or just put one resistor on the stepstick. Pulled down to GND or pulled up to +5V?

[kAdonis]

You wrote you have an Azteeg X5 mini, you need to pull-up to 3,3V! I dont know. I would try it with a modified jumpercable, whatever is easiest

[klcjr89]

Do I need pull ups on SDO, SDI, and SCK as well?

[kAdonis]

SDO and SDI are already pulled up on the Azteeg board, as i wrote above. I dont know about SCK

[klcjr89]

I looked at the diptrace file and didn't see any pullup resistors for the 3 SD card breakout pins, they go straight to the LPC1769 chip.

[comps]

You don't have to go overboard with external pulling. For most pins (CS, MOSI, CLK, etc.), it's not an issue because these are "output" pins of the MCU and as such are "actively controlled" as logic high or low. The issue with MISO in the way we connect TMCs with Marlin is that it's a shared line driven by a (selected) SPI slave and it can go floating between one CS switching off and another CS switching on.

[klcjr89]

@comps So what is your recommendation on what I should do? I have resistors in hand and want to do it proper and not to overdo it on pins that don't need it.

[comps]

I would suggest trying to actually debug the issue, like others suggested. Isolate a reliably working setup and do incremental changes, testing after each - connecting one 5160, if issues arise, disconnect the encoder from the LCD panel and see if that has any effect, etc. Don't shoot in the dark, try to narrow down the problem.

[klcjr89]

What if the problem doesn't occur with only one 5160? I want to run 5160s in all driver slots

[kAdonis]

@klcjr89 I didnt want to confuse you. A pullup on CS was just one thing to try, in the process of narrowing down the issue @gloomyandy is much more experienced than I am, and @comps your explanation makes perfectly sense

I found the diptrace files here: https://reprap.org/wiki/Azteeg_X5_mini here is the pullup on MISO (10k):

[gloomyandy]

The purpose of these step by step tests is not to limit you to just one driver but to try and work out what exactly is causing your problem. So first we check the each driver will work OK on its own (which probably means that all of the drivers are ok). Then we check that each socket will work on its own (which probably means that all of the sockets are ok). Then we add the drivers one at a time checking that things are working at each stage. At then end of the process you will either have a working system (because in the process of doing all of the tests you managed to "fix" the issue) or we will have more information as to what may be the cause. I still suspect that with those drivers you are drawing too much current from the board, but who knows it is just a guess, doing the tests will help us to find out.

[klcjr89]

@kAdonis Does SCK need a 10k pullup? I don't see one in the diptrace file. Thanks!