Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't receive in one wire mode #321

Open
michaelosthege opened this issue Jun 6, 2024 · 1 comment
Open

Can't receive in one wire mode #321

michaelosthege opened this issue Jun 6, 2024 · 1 comment

Comments

@michaelosthege
Copy link

Hello,

first of all thank you for writing this library!

I am trying to use EspSoftwareSerial to talk bidirectional UART with a TMC2209 stepper driver (a Silent 2209 V3.0 stick to be precise](https://wiki.fysetc.com/Silent2209/#v30) using the TMCStepper library.
On my WT32-ETH01 there are no more built-in serial pins available, because they're used for the ethernet.

Why opening a ticket here?

Other people had success in communicating bidirectional UART with TMC2209 sticks using Arduino SoftwareSerial or built-in ESP-32 serial pins with TMCStepper, so in principle this works fine.

As described below, I got the correct signal on the oscilloscope, but could not capture the data via EspSoftwareSerial at the same time.

Quirks to be aware of

TMC2209 stepper driver sticks come in different versions and the pinouts found on the internet are totally messed-up and confusing.

Relevant here:

  • RX on the driver stick is where it sends data.
  • TX on the driver stick is where it receives data (it's labeled CLK on my "Silent 2209 V3.0" version..)
  • The chip only as one PDN_UART and both of the above pins connect to it as shown here 👇

TMC2209V30_stick_circuit

This is some kind of weird "UART but over one wire" design, not to be confused with 1-wire which is a totally different thing.

How it should have worked

I ran out of pins and had to use GPIO2 (for TX) and GPIO12 (for RX) for the UART connection.
EspSoftwareSerial refuses to use GPIO2 by default (#261 and #249), but one can override it:

class YoloGpioCapabilities : private EspSoftwareSerial::IGpioCapabilities {
public:
    static constexpr bool isValidPin(int8_t pin) { return true; }

    static constexpr bool isValidInputPin(int8_t pin) { return true; }

    static constexpr bool isValidOutputPin(int8_t pin) { return true; }

    static constexpr bool hasPullUp(int8_t pin) { return true; }
};
// Construct software serial UART to the TMC2209 without checking GPIO capabilities...
EspSoftwareSerial::BasicUART<YoloGpioCapabilities> StepperSerial(12, 2);  // (RX, TX)

TMC2209Stepper driver(&StepperSerial, R_SENSE, DRIVER_ADDRESS);

With this, I can initialize and test the UART communication:

StepperSerial.begin(115200);

driver.test_connection();

This gives a garbage signal, looking like this on both TX and RX:

image

enableRx(false) gives a clean signal (but receive does not work)

By disabling the RX functionality...

StepperSerial.begin(115200);
StepperSerial.enableRx(false);

driver.test_connection()

...suddenly the signal clears up!

Probing the TX pin shows the query to the 6F address made by the call to test_connection():

image

image

We can also see the bleed-through of the response from the other side of the 1K resistor!

Probing the RX pin 👇 gives a clear response signal.

image

To me this looks like TX signal (via the 1K resistor) to the RX pin causes the interrupts to fire, and then something happens on the microcontroller side which disrupts the signal, causing the 00-00-00-00... from above?

When looking into the EspSoftwareSerial code, I found mentions of the one-wire mode, so I though that this might implement ignoring the interrupts while TX is firing?

Setting TX == RX

When setting TX and RX to the same pin I expected the library to work in a one-wire mode and ignore RX interrupts while firing TX.

Instead, there was no more signal at all!
The GPIO12 pin remains stable at 3.22 V even without anything connected to it.

If I would see the TX signal, I would like to connect GPIO12 directly to PDN_UART of the TMC2209, expecting the same signal pattern as above.

Conclusion/Questions

  • Why is the signal disrupted by enableRx(true)?
  • How is one-wire mode supposed to work? Could I use it here?

@dok-net could you give me a hint I am looking at a bug, or a misunderstanding on my side? thanks!

@michaelosthege
Copy link
Author

We're still stuck on this matter. With Arduino SofwareSerial we were able to do bidirectional communication, which appears to confirm that it's a software bug. Maybe @dok-net or @plerup can help us with interpreting these symptoms?
thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant