P2 Module TMC2209 Driver - TX/RX Pullup Issue Possibly Preventing Bidirectional Comms

[willdueease]

Greetings!

I’m seeing an issue in migrating from the Argon to a P2 board.

I’m running a TMC2209 stepper driver on an inexpensive breakout board, V3.1 of this board It’s connected to TX/RX of Serial3 on the P2, was on Serial1 of the Argon.

Theres something different with the pullup/pulldown on the P2 thats causing communication to not work. I am able to successfully send data to the driver, but am unable to receive any replies from it, so I cannot query any registers or anything like that.

This chip is kind of strange where both TX and RX go to the same pin on the IC itself, with a 1k in between them. See following post for screenshot (I can’t upload more than two pictures as a new user)

I’m guessing that the P2 is also pulling the pins in different directions, and the IC is no longer able to drive the line low enough when sending data. See the following scope output:

Heres the same scope output when connected to Argon.

Is this expected behavior? Was I just lucky with the Argon? Is there any software pullup i can manipulate on the Serial3 pins, or is it hardwired in some way to allow it to also be SPI?

I can provide code and equivalent schematics of what I’m doing of that helps diagnose.

Thanks for any assistance!

[willdueease]

Schematic of break out board showing physical connection of the TX/RX to each other.

[rickkas7]

I think it is a pull-up. For reasons that are not obvious to me, the P2 includes a software pull-up (42K) on RX.

particle-iot/device-os/blob/develop/hal/src/rtl872x/usart_hal.cpp#L193

This does not appear to be the case on other devices.

For example, on Gen 3 (Argon), it’s just INPUT (no pull):

particle-iot/device-os/blob/develop/hal/src/nRF52840/usart_hal.cpp#L169

[willdueease]

Is is possible to remove the pullup in user code?

[rickkas7]

You can try adding a call to hal_gpio_mode() after Serial1.begin(). I’m not positive the setting will stick, but it might:

void setup() {
    Serial1.begin(9600);
    hal_gpio_mode(RX, INPUT);
}

You can’t use pinMode() because it has a safety check that prevents it from being able to set the mode of a UART pin when the UART is active.

[willdueease]

Hmm, not having luck on that, I think its complicated by the fact that the TX/RX are bridged at the IC, so the pullup on the TX pin is also affecting the line level of the RX.

Is there a way to turn off the pullup on both the TX and RX and let the device control the line direction?

I tried various combinations of this:

  Serial3.begin(115200);
  hal_gpio_mode(D16, INPUT);
  hal_gpio_mode(D15, OUTPUT);

(I’m using Serial3, I think those are the right pins, D16 = RX, D15 = TX)

Setting the TX to OUTPUT makes the serial non-functional which I think is heartening that the settings are “sticking,” but is not yielding the desired results, hah.

[rickkas7]

I don’t think the pull-up on TX should make a difference. The reason is that once in UART mode, the TX pin is push-pull so it will always drive the pin either high or low in full-duplex mode overriding any pull resistance.

The P2 doesn’t support half-duplex mode, but neither did the Argon. TX pull could make a difference in half-duplex mode.

I’m not sure why the sensor isn’t working.

[no1089]

@willdueease Can you try lowering the value of the 20K pull down on UART to something like 4.7K?
That should provide more current to pull down the RX line.

I’m not sure, but Diodes or buffers might also do the trick to isolate RX/TX.

[willdueease]

Unfortunately for me that 20k pulldown is not easily changeable on the off-the-shelf module (well, 0402’s are a bit out of MY comfort zone anyways!)

That said, I’ve tried putting some pulldowns of various values onto the RX pin of the module on my breadboard (electrically I think this is the same thing? anything I add will be in parallel with the 20k, but I can still arrive at a target resistance), and it seems to mostly just shift the whole signal around. If I put a strong enough pulldown where the troughs of the RX signal is in the right voltage to be read as bits, the TX no longer works, as it’s too low now.

I’ll look into some kind of buffering/diode hardware solution.

Is half duplex support on the roadmap? or removing the pullup at the HAL layer?

[no1089]

Ah, I thought it was on your PCB. 0402 is indeed on the lower end of what I’d like to tinker with as well.

Your use-case is quite unique, and not one I’ve seen before - using UART in half-duplex mode. I’ll have to check with the team.

Software Half Duplex UART For AVRs | Hackaday shows an intersting circuit that uses a diode and NPN transistor to split the UART.

[no1089]

Engineering have indicated they are looking into this issue as well!

[willdueease]

Thanks for the help! I was also kind of surprised by the weird semi-custom one wire serial that Trinamic implemented, and was (happily) surprised when it…just worked…on the Argon, hah.

FWIW I also tried connecting these devices through the recommended SC16IS750 I2C/UART Extender, and had similar behavior. They have an RS485 mode, but the TMC220x isn’t actually RS485 it’s their own weird thing.

Anyways, thanks again for the help, I’ll look into external circuits and report if get anything working, lmk if eng has any input.

[no1089]

My pleasure, and sorry for all the hassle. It’s a pretty strange scenario - not something I’d expect on modern devices where pins are cheap to add.

I’ll let you know if there is a PR in the works that addresses this, or allows you to configure the HAL.

[willdueease]

I see in OS 5.3.1 there was a PR to remove the pullups on the serial ports [rtl872x] Dont enable usart RX/TX pullups by scott-brust · Pull Request #2646 · particle-iot/device-os · GitHub

I can report that I am now able to communicate with my TMC2209 modules.

For anybody else who wants to use these modules, this is the hardware setup that I have working:

Two FYSETC TMC2209 V4.0 modules, in “daisy chain” configuration where both modules TX/RX are connected to Serial 3 port of the P2. This allows one serial port to control two modules, provided that the address pins (MS1, MS2) are configured to be unique. This is how I have them configured:

I am using this library with success. GitHub - teemuatlut/TMCStepper

Thanks for the help!