Can't make simple example work

[soswow]

I know it's a horrible title. Feel free to change it.

Here is my setup:

• Arduino Nano. Probably some clone.
• Stepper- NEMA 17 - 48 mm LDO-42STH47-1684A
• Chinese clone of watterott's stick
• 12V 3A power supply
• Protector board (with a bunch of diodes, I assume)

Initially, I didn't know about Chinese clones having this non-SPI soldered bridge thing. It didn't work and the motor was making high pitch noises. I've desoldered one resistor and connected two other bridges according to instructions in one of Merlin issues.

It still doesn't work 😢Simple example doesn't work as is. Nothing happens. I can turn rotator with my fingers. When I disabled stealthChop motor starting vibrating making sound, but not turning.

I am not sure if I was able to kill the driver or I am missing anything else =( Thought maybe you have some ideas on how to debug this thing. I don't have a good scope, though I have a simple logic analyser and a good multimeter.

[soswow]

I have different microcontrollers, motors only one driver of this type. (have many other DriverSticks) So I could troubleshoot with those, but I don't feel it's where the problem. =\

[teemuatlut]

Try switching the driver to another one, like A4988. That way you can test if the issue is with SPI or the rest of the wiring.
Is your FYSETC driver version 1.0 or 1.1?

[soswow]

it's 1.0
Are you saying I should keep the Simple example but switch to A4988? ... I mean' it should work, I guess. Just dir and step + EN pins are needed to drive it ...

[teemuatlut]

Exactly. Disconnect the SPI wires though.

[soswow]

It took me some time to remember to connect Sleep to Reset as on this diagram:

I've used the simplest program to run it:

// defines pins numbers
const int stepPin = 8; 
const int dirPin = 7; 
 
void setup() {
  // Sets the two pins as Outputs
  pinMode(stepPin,OUTPUT); 
  pinMode(dirPin,OUTPUT);
}
void loop() {
  digitalWrite(dirPin,HIGH); // Enables the motor to move in a particular direction
  // Makes 200 pulses for making one full cycle rotation
  for(int x = 0; x < 200; x++) {
    digitalWrite(stepPin,HIGH); 
    delayMicroseconds(500); 
    digitalWrite(stepPin,LOW); 
    delayMicroseconds(500); 
  }
  delay(1000); // One second delay
  
  digitalWrite(dirPin,LOW); //Changes the rotations direction
  // Makes 400 pulses for making two full cycle rotation
  for(int x = 0; x < 400; x++) {
    digitalWrite(stepPin,HIGH);
    delayMicroseconds(500);
    digitalWrite(stepPin,LOW);
    delayMicroseconds(500);
  }
  delay(1000);
}

With all that I was able to make it run (using A4988)!

But when I switched to your simple script:

#define DIR_PIN   7
#define STEP_PIN  8
#define EN_PIN    9
#define CS_PIN    17

bool dir = true;

#include <TMC2130Stepper.h>
TMC2130Stepper driver = TMC2130Stepper(EN_PIN, DIR_PIN, STEP_PIN, CS_PIN);

void setup() {
	Serial.begin(9600);
	while(!Serial);
	Serial.println("Start...");
	driver.begin(); 			// Initiate pins and registeries
	driver.rms_current(1000); 	// Set stepper current to 600mA. The command is the same as command TMC2130.setCurrent(600, 0.11, 0.5);
	driver.stealthChop(0); 	// Enable extremely quiet stepping
	
	digitalWrite(EN_PIN, LOW);
}

void loop() {
	digitalWrite(STEP_PIN, HIGH);
	delayMicroseconds(10);
	digitalWrite(STEP_PIN, LOW);
	delayMicroseconds(10);
	uint32_t ms = millis();
	static uint32_t last_time = 0;
	if ((ms - last_time) > 2000) {
		if (dir) {
			Serial.println("Dir -> 0");
			driver.shaft_dir(0);
		} else {
			Serial.println("Dir -> 1");
			driver.shaft_dir(1);
		}
		dir = !dir;
		last_time = ms;
	}
}

With EN_PIN, CS_PIN not connected.
Motor makes high pitch sound, not turning and stepper goes hot quickly (I've disconnected before it burned)

[soswow]

Update: Ok. I've changed delayMicroseconds to 500 as in my other example and it spins now. But it doesn't change direction. Multimeter doesn't show change on D7 pin.

[soswow]

I've added 1 second delay before each of driver.shaft_dir(); - didn't help. It stops and keep rotating in the same direction.

[soswow]

Ok. I've looked what shat_dir is doing. It relies on TMC_MOD_REG, which is SPI way of controlling direction. So I assume test has succeeded - it works with A4988. Kinda.

[soswow]

No idea how continue debugging?

[prathameshjakka]

hey I'm getting the same problem that you have specified

-driver heats up too much ( too hot to touch )
-the motor is moving in a single direction then pauses and moves in the same direction
-also, the dir value is not stable it's fluctuating between 1 and 0

[prathameshjakka]

Can this stepper motor library be used with the accel stepper library?

[soswow]

@prathameshj There was an issue about that #33

Btw, The movement in one direction I've described was about trying this lib with classic pololu stick

Edit:
Also, it's ok for driver to heat up. It can be over 80 or 100 some cases. So, that's not a big problem.

[soswow]

Ok. Here is what I've done:
I double check my SPI pin configuration. Since I switched to my old Seeeduino v2.2 (Which has arduino compatible layout)

SDI - MOSI - 11 #green
SDO - MISO - 12 #blue
SCK - SCK  - 13 #orange
CS  - SS   - 10 #yellow

I also added driver.microsteps(0); to my code, since I found out by deafult it goes full microsteping.

[soswow]

I don't know how SPI works exactly, but I would assume SCK should have a constant frequency. I am not sure what it should be, but I assume anything lower than my Arduino internal clock, which is 16MHz.
I was trying to debug SPI channel with my Logic Pirate.
I tested and retested the analyzer by using test pin. I was trying to see at least clock signal on pin 13 since this is the one on Arduino is SCK one when using SPI. Just to make sure I've even run a blink program since 13 is connected to internal LED. I've made 20 ms duty cycle with 10ms on and 10ms off. I could see this clock on the analyser. All this says that it works fine.
But when I run in with Simple_TMC2130 it just shows it's always ON. I am confused at this point.

[soswow]

Maybe ISP doesn't clock on SCK between transactions? I couldn't find a definite answer anywhere. In this case, it's ok I don't see any signal there since this only happens during setup.

I guess another option would be to use software SPI. Just because I don't have any other idea.

. + I will order some other stepper driver with v1.1. Maybe I have busted driver 🤷‍♂️

[teemuatlut]

shaft_dir does not toggle the DIR_PIN but rather uses the driver's internal register to change the rotation.

---

the dir value is not stable it's fluctuating between 1 and 0

That would be intentional.

---

SCK line is active during a transaction, but not all the time. The max frequency is about half that of the internal frequency of the stepper driver logic; roughly 6MHz.

---

I was testing some new driver last night and had communication issues with the driver as well. I'm not sure what would have changed but the commands sent were not correct. I'll be looking more closely into this so stay tuned. Maybe it affected TMC2130Stepper as well.
In the mean time if you want, you can try older versions of the library, just in case something has been broken.

[teemuatlut]

I tested the "Simple" example from library version 2.3.0 and after setting up the correct pins, the code worked as expected.
This was with Mega + RAMPS1.4 + FYSETC v1.1 driver.

Your driver actually does look a bit smudged but it's hard to tell.
The symptoms would indicate that your driver would be configured to standalone mode where stepping works but SPI communication does not. However, your driver looks like you've what is necessary to switch the modes.
Could you add this to your code, between Serial.println("Start..."); and driver.begin();:

pinMode(CS_PIN, OUTPUT);
digitalWrite(CS_PIN, HIGH);
Serial.print("DRV_STATUS=0x");
Serial.println(driver.DRV_STATUS(), HEX);

Then report back with the response.

EDIT: Another suggestion would be to try software SPI.

[soswow]

I've tried prev. version of library. Didn't help.

When I had stealthChop set to 0:
On the initial start after power up only V5 line I get this

DRV_STATUS=0x0

But after turning power line on and restarting I get this:

DRV_STATUS=0x60000000
# 0110000000 0000000000000000000000

I switched on stealthChop back on and I get now these:

DRV_STATUS=0x81090000 # On initial start up with motor power on already
# 1000000100 00100 1 0000000000000000
#                  ^ full step active indicator, which is correct. I have driver.microsteps(0);
DRV_STATUS=0xE0090000 # On each consequative restart
# 1110000000 00100 1 0000000000000000

I have unused mega and RAMPS laying around. I can try with them. I just thought my setup with breadboard has less variables. I guess I would need to resolder headers for that.

Next thing I try is software SPI

[soswow]

I've tried Software SPI. IT already had status printout (but after digitalWrite(EN_PIN, LOW); line). I've added HEX output just in case.
Visual result is exactly the same as with normal SPI: it makes noise without movement with stealthChop(0) and it doesn't do anything with stealthChop(1). I've also added driver.microsteps(0); for both tests:

With stealthChop(1):

# 0b1100000000 00100 1 0000000000000000
# 0xD8090000

With stealthChop(0):

# 0b1110100000 00100 1 00000 000 0 0 0 1 0 1 1 0
#                                      ^ short to ground? :-\
# 0xE8090016

[teemuatlut]

The Simple sketch was meant to be ran with native 256 microstepping, so when you're switching to fullsteps you're also asking the driver to run 256 times faster. Try increasing step delays 2560.

The driver needs to be fully powered on from +12V as well for communication to work.

[soswow]

Ok. I c. That makes sense. I can just leave it as is without full step. For some reason I thought full step will make it cleaner experiment.

Does my debugging report tells you anything? I didn't understand from docs what first 10 bits represent. If first in order is 0th one

[teemuatlut]

DRV_STATUS=0x0 is because the driver has no VMOT power.
DRV_STATUS=0x60000000 would indicate triggered open load indicators. Possibly due to very high requested stepping speeds.
DRV_STATUS=0x81090000 is standstill, stallguard and CS_ACTUAL=1. Would've expected to see factive there too.
DRV_STATUS=0xE0090000 a more plausible result but there are error flags raised.
DRV_STATUS=0xD8090000 same as previous with short to ground flags switched.
DRV_STATUS=0xE8090016 still roughly the same with error flags but this time with a SG_RESULT added.

When reading the register output, the first number on the left, is the most significant bit.
So as an example 0xA is 0b1010 and means that bits number 3 and 1 are set.

[soswow]

I tried new delay. No spinning, but it got louder and vibrates a lot now. I will attach video in next post.

Current status is this.

0xE8090016

standstill indicator
|       short to ground indicator phase B         
↓       ↓
1 1 1 0 1 0 0 0 000 01001 0 00000 0000010110
              ↑     ↑     ↑ ↑     ^ SG_RESULT
              |     |     | ^ reserved
              |     |     ^ full step active indicator
              |     ^ CS ACTUAL
              | ^ reserved
              ^ stallGuard2 status

Is this how I should read it then?
All that with driver.stealthChop(0);
When I turn it on, I have

DRV_STATUS=0b10000000000010010000000000000000
DRV_STATUS=0x80090000
standstill indicator
|       short to ground indicator phase B         
↓       ↓
1 0 0 0 0 0 0 0 000 01001 0 00000 0000000000
              ↑     ↑     ↑ ↑     ^ SG_RESULT
              |     |     | ^ reserved
              |     |     ^ full step active indicator
              |     ^ CS ACTUAL
              | ^ reserved
              ^ stallGuard2 status

with no noise and no movement.

I am still using SW SPI, but I didn't change pins for it SPI cabels. I hope it's ok.

[teemuatlut]

They look like valid responses but you still have some error flags.
You should try running it with a RAMPS board and see if that changes anything.

[soswow]

Is there any nice instruction on how to wire stuff in and what pins to choose in the code etc? I guess I will have to resolder driver headers, since SPI ones should not go into RAMPS.

Ignore that. I'll figure this out.

[soswow]

Oh, that's the video I promised before https://photos.app.goo.gl/uXvsUa5BhQqL4dRf2

[soswow]

Holly shit.

It works!

With Mega and ramps! Now I need to figure out what's the difference between this and my previous setups. Power is the same. It's just another Microcontroller =\

[soswow]

Thank you @teemuatlut ! Let me close this issue since I made it work. But I will report when I figure out what was wrong.

[wolfgangmauer]

@soswow I'm trying a UNO right now and I'm unsuccessful, did you find the difference ?