comunication only in one direction

[miszaklajent]

When I upload MoveAtVelocity bidirectional example, the motor starts moving, but I get "Stepper driver not setup and communicating!" spam in the serial monitor. 1k resistor between rx and tx is in place, and rx from the driver is connected to tx on the board.

[peterpolidoro]

Are you using the latest version of the library?

[miszaklajent]

I think so, I have 9.0.4 installed

[peterpolidoro]

Can you try running the TestCommunication example and see what happens?

[miszaklajent]

I get this in serial monitor: "Stepper driver is not communicating! Try turning driver power on to see what happens."

all power is supplied, and the motor is spinning while running other examples, but I don't get any data back (like for example stall detection)

[peterpolidoro]

You are using a Pico, correct? Perhaps try using different pins. I have not used a Pico yet, but according to this pinout maybe you want to try pins 6 and 7 or 11 and 12? One of the pair listed as an option for UART1.

[miszaklajent]

UART1 are 4 and 5, 8 and 9. https://learn.adafruit.com/assets/99339. I just realized, that I had TX from pico connected to RX on a driver, and RX from pico connected to TX from pico via 1k resistor. If I connected it like here: it outputs the same thing in the serial monitor while running TestCommunication example, but motor doesn't spin when I upload MoveAtVelocity bidirectional but makes weird noises and draws almost 0.5a on 24v.

[peterpolidoro]

That image in the adafruit link shows that pin 8 is ground. Where did you get the 4,5 or 8,9 numbers? Maybe we are looking at different versions of the board?

The resistor needs to be between the microcontroller TX line and the TMC2209 line so when they are both outputs they do not short out.

Some TMC2209 driver boards have a UART pin and a PDN pin that need to be soldered together on the driver board for them to be connected, but I am not sure which driver board you are using.

[miszaklajent]

I'm sorry, I was referring to GPIO numbers, my fault. this is what I'm running right now (sorry for a image from paint), as I said earlier, if I connect it like this: not only I don't get any data back, but also motor is not spinning when using MoveAtVelocity bidirectional example but also it's making weird noises.

[peterpolidoro]

The bigtreetech documentation shows:

[miszaklajent]

I tried connecting it like this but it doesn't work either. If I connect it like in this picture:

or this one:

then I get the effect like this (while running MoveAtVelocity bidirectional example): https://youtu.be/qdcqqpEc93A

however, if I connect it like in this picture:

then I get the motor spinning. https://youtu.be/Vxi8R2oiNr0

in both scenarios, I get "Stepper driver not setup and communicating!" in MoveAtVelocity example and "Stepper driver is not communicating! Try turning driver power on to see what happens." in TestCommunication example

I have tried various serial ports with the same results.

[peterpolidoro]

Do you have an oscilloscope? If so, can you please look at the uart line for a very simple program that does something like Serial.println(driver.getVersion(), HEX); delay(1000); in a loop? You should see a set of bytes for the output to the driver, then another set of bytes returning from the driver. I would like to see the waveform for the two sets of bytes and I am curious what is the returned value of the version.

[miszaklajent]

I, unfortunately, don't have an oscilloscope. I have to get on, but for now, we have to deal without it.

[BeptoBepis]

Hi @peterpolidoro, I am running into this issue as well. I also do not have an oscilloscope but can 99% confirm that the issue has to do with the library. Some details that may be helpful:

Running an WROOM ESP32U DevkitC V4 on serial2, TX/RX on pins GPIO 16 and 17, 115200 BAUD BIGTREETECH TMC2209 V1.3, EN grounded, MS1 grounded, MS2 grounded, pin 4 ("rx") UART connection

This was my first time setting up a stepper driver so I spent hours trying to figure out what was wrong with my wiring/code/etc. Turns out it was just an issue with the current version of this library.

When reverting to version 8.0.7 I can control the driver and read settings with no issues When using the teemuatlut/TMCStepper I can control the driver and read settings with no issues When on 9.0.4 I can control the TMC2209 (velocity/direction changes work) but do not have communication. E.g. when trying to get settings and status it returns the log below. It is communicating because this response is consistent and if I pull the UART wires the response is all 0's. The overtemp/short warnings are also incorrect, the board is not getting hot and is still functional. I have tested this across multiple ESP32 boards and TMC2209 drivers, it is not isolated to one set of hardware.

For testing both 8.0.7 and 9.0.4 I used the example code, only modification was to set HardwareSerial & serial_stream = Serial2;

---

getSettings() settings.is_communicating = 0 settings.is_setup = 0 settings.software_enabled = 0 settings.microsteps_per_step = 0 settings.inverse_motor_direction_enabled = 0 settings.stealth_chop_enabled = 0 settings.standstill_mode = normal settings.irun_percent = 0 settings.irun_register_value = 0 settings.ihold_percent = 0 settings.ihold_register_value = 0 settings.iholddelay_percent = 0 settings.iholddelay_register_value = 0 settings.automatic_current_scaling_enabled = 0 settings.automatic_gradient_adaptation_enabled = 0 settings.pwm_offset = 0 settings.pwm_gradient = 0 settings.cool_step_enabled = 0 settings.analog_current_scaling_enabled = 0 settings.internal_sense_resistors_enabled = 0

---

---

hardwareDisabled() hardware_disabled = 0

---

---

getStatus() status.over_temperature_warning = 1 status.over_temperature_shutdown = 1 status.short_to_ground_a = 1 status.short_to_ground_b = 1 status.low_side_short_a = 0 status.low_side_short_b = 1 status.open_load_a = 1 status.open_load_b = 0 status.over_temperature_120c = 1 status.over_temperature_143c = 1 status.over_temperature_150c = 1 status.over_temperature_157c = 1 status.current_scaling = 5 status.stealth_chop_mode = 0 status.standstill = 1

---

[peterpolidoro]

I am sorry you both have spent so much time struggling with a new bug in the library! This is why it is helpful for so many people to test it on many different setups.

It seems to work fine on my setup, but obviously there is a new flaw somewhere. I am trying to think of how best to debug this without oscilloscopes.

It is also possible that some of the dependencies that this library uses are different for different setups and there could be a problem with one of those. For example, I added a call to serial.flush(). Maybe the flush function is not working properly for some microcontrollers.

I will keep looking for problems with my code. I also removed some delays that are perhaps still necessary on some setups.

If I create a debug branch is it possible for you both to test changes to see if any of them fix problems on your setup?

[peterpolidoro]

Ok I put back in a delay that may or may not help. Please test the code on the latest commit of the debug branch and see if you are still experiencing problems. Thanks!

[miszaklajent]

I'm testing this debug branch right now, and it looks like it helped something. The motor is spinning when connected correctly(rx to rx hard, and rx to tx via resistor) unlike last time, the StallGuard example is giving back some data, and it seems not to be random because if I manually stall the motor by hand, than stall_guard_result I decreasing, Test communication example is writing: "Stepper driver is setup and communicating! Try turning driver power off to see what happens." When driver is powered

and this: "Stepper driver is not communicating! Try turning driver power on to see what happens." When driver is depowered

Is there any additional info I can provide to help you with development? I'm happy to help you.

[peterpolidoro]

So does that mean it is working properly for you now? Are you still running into any obvious problems? I think I will push these changes up as a new release version since I do not think they will hurt anything and they seem to help.