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

willdueease · March 16, 2023, 8:23pm

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 · March 16, 2023, 8:25pm

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

rickkas7 · March 17, 2023, 3:52pm

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.

github.com

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


      
          }
          // Configure TX/RX pins
          if (uartInstance == UART2_DEV) {
              Pinmux_Config(hal_pin_to_rtl_pin(txPin_), PINMUX_FUNCTION_LOGUART);
              Pinmux_Config(hal_pin_to_rtl_pin(rxPin_), PINMUX_FUNCTION_LOGUART);
          } else {
              Pinmux_Config(hal_pin_to_rtl_pin(txPin_), PINMUX_FUNCTION_UART);
              Pinmux_Config(hal_pin_to_rtl_pin(rxPin_), PINMUX_FUNCTION_UART);
          }
          PAD_PullCtrl(hal_pin_to_rtl_pin(txPin_), GPIO_PuPd_UP);
          PAD_PullCtrl(hal_pin_to_rtl_pin(rxPin_), GPIO_PuPd_UP);
          // Configure CTS/RTS pins
          if (ctsPin_ != PIN_INVALID) {
              Pinmux_Config(hal_pin_to_rtl_pin(ctsPin_), PINMUX_FUNCTION_UART_RTSCTS);
              PAD_PullCtrl(hal_pin_to_rtl_pin(ctsPin_), GPIO_PuPd_UP);
          }
          if (rtsPin_ != PIN_INVALID) {
              Pinmux_Config(hal_pin_to_rtl_pin(rtsPin_), PINMUX_FUNCTION_UART_RTSCTS);
              PAD_PullCtrl(hal_pin_to_rtl_pin(rtsPin_), GPIO_PuPd_UP);
          }
          UART_InitTypeDef uartInitStruct = {};

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

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

github.com

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


      
          AtomicSection lk;
          
          
if (isEnabled()) {
              end();
          }
          
          
nrfx_prs_acquire(uarte_, interruptHandler_);
          
          
hal_gpio_write(txPin_, 1);
          hal_gpio_mode(txPin_, OUTPUT);
          hal_gpio_mode(rxPin_, INPUT);
          hal_pin_set_function(txPin_, PF_UART);
          hal_pin_set_function(rxPin_, PF_UART);
          
          
nrf_uarte_baudrate_set(uarte_, (nrf_uarte_baudrate_t)nrfBaudRate);
          nrf_uarte_configure(uarte_,
                  conf.config & SERIAL_PARITY_EVEN ? NRF_UARTE_PARITY_INCLUDED : NRF_UARTE_PARITY_EXCLUDED,
                  conf.config & SERIAL_FLOW_CONTROL_RTS_CTS ? NRF_UARTE_HWFC_ENABLED : NRF_UARTE_HWFC_DISABLED);
          nrf_uarte_txrx_pins_set(uarte_, pinToNrf(txPin_), pinToNrf(rxPin_));
          
          
if (conf.config & SERIAL_FLOW_CONTROL_CTS) {

willdueease · March 21, 2023, 2:10pm

Is is possible to remove the pullup in user code?

rickkas7 · March 21, 2023, 2:16pm

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 · March 21, 2023, 2:48pm

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 · March 21, 2023, 3:37pm

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.