Issue with Bus Servo Driver Board and Pico 2 over UART

Products & Technology XIAO
,
1

Dear community,

I am having trouble trying to control a Feetech STS3215 through a Bus Servo Driver Board with a Raspberry Pi Pico 2 over UART.

The Driver Board works fine over USB, I can move the motor with a workstation and the scservo_sdk library.

When moving onto the Pico 2, I’ve been trying to simply ping the motor as especified in the Feetech protocol. I know with certainty its ID and baudrate, as I can previously set those via USB. As stated in the documentation, I have removed the jumper cap and connected the Pico TX with the Driver Board RX, and vice versa. Note that the pads JP1 and JP2 are soldered in my v1.0 board, though it should have nothing to do with UART.

All I seem to get is an echo of my ping, and even other random messages. I have confirmed this both by adapting the scservo example, and by creating my own MicroPython script. Even if no motor is connected to the Driver Board I get a reply, which makes no sense. I have checked with a multimiter, but the RX and TX pins of the board are not shorted. I have reproduced this issue with two different Driver Boards, Feetech motors and Pico 2 boards.

I would appreciate any help.

2

Hi there,

So, I have a couple on the bench , getting ready for some project setup and test.
I don’t think it’s a Pico logic-level or polarity problem.
That “I get a reply even with no servo connected” is the giveaway: you’re not actually talking to the servo bus — you’re seeing the board itself / the USB-UART path echoing or driving the line.

What’s most likely happening

On the Bus Servo Driver Board, there are two different modes, and they’re selected by hardware jumpers/solder bridges:

  • UART (MCU) mode: use the RX/TX pins to a microcontroller, and do not short the 2-pin header.
  • USB mode: you must bridge the solder pads on the back and short the front 2-pin header.

You say: JP1/JP2 are soldered on v1.0. That sounds exactly like the board is still configured as “USB path active,” so the USB-UART circuitry can end up loading/driving the UART pins. That can produce:

  • echo of your own ping
  • garbage/random bytes
  • “responses” even when no servo is attached

Try this

  1. Put the board into true UART mode
  • Remove the solder bridge on the back pads (JP1/JP2) so those pads are open (UART mode). (USB mode requires them bridged .)
  • Make sure the front 2-pin is NOT shorted (UART mode expects it open ).
  • Unplug USB from the driver board while testing UART-to-Pico (so the USB-UART chip isn’t powered and fighting the line).
  1. Verify with a dead-simple electrical test
  • With no servo connected, send bytes from Pico.
  • If the board “replies” again, it’s still not in UART mode or the board TX is being driven by something else.
  1. Then worry about the usual UART basics
  • Pico UART should be 8N1 at the known baud, common ground, correct TX↔RX crossing.
  • Servo power must be correct (STS series often wants higher than 5V).

Because in USB mode the board is intentionally configured as a USB-UART bridge; in your case, that same bridge is likely still “in circuit” when you try to use the external RX/TX pins — so they aren’t getting a clean path to the servo bus.

If you want, paste me the exact photo/labeling of your v1.0 board back side (JP pads) and I’ll tell you exactly which bridge to open and what “UART mode” should look like.

HTH
GL :slight_smile: PJ :v: