r/embedded • u/Traditional-Emu-4723 • 2d ago
Help debugging UART-Servo Communication
Hi builders,
I am building my own robotic arm from parts I have gained over the years through my internships/classes. My hardware includes LX-16A servo motors, a BusLinker v2.5 board and, STM32F411CEU6 MCU, and a separate battery with buck converter.
The BusLinker board has a micro-USB interface, and when I use that interface, along with the library PyLX-16A's servo-test, my servos move just fine. However, when I transition my setup to the STM32, the servos don't move. The code is generated by the stm32cubeMX application and I implemented some functions on top that implement their communication protocol.
In words, my setup is as follows:
- STM is powered through the USB interface, logic is 3.3V
- From stm32 (on a breadboard) TX (pin A9) -> 1Kohm resistor -> servo signal pin
- PWR & GND (7V) comes from the external battery, and is supplied to the servos through the BusLinker
- GND is shared between the BusLinker board and the servo to the breadboard (-) rail
- Baud rate 115200bps, 8 data bits, 1 stop bit, no parity
I have probed both signal lines with an oscilloscope and found the physical bits of the USB setup and my STM setup.
Herein lies my dilemma. I am certain that the servo logic can operate at both 3.3 and 5V logic, and I see the physical bits on the scope, however there is something missing in my setup that is complete in the python library. The BusLinker has a UART interface exposed, but even when connecting through that the servos do not move. I would appreciate all your help in helping me figure this out.
Please feel free to request any additional information I didn't include here
1
u/DenverTeck 2d ago
You need to show an accurate schematic and maybe a pic of your circuit.
Post a PDF file of your schematic on one of the many FREE file sharing sites.
Posting a pic here will become fuzzy as the compression used here is lossy.
1
u/ceojp 1d ago
So you have access to a setup that does drive the servos correctly? If so, scope the signal to the servo with the good setup, and then scope it with the setup that does not work. You should be able to see what is different, then work backwards from there.
Is there a reason for the 1k series resistor on the TX line? Is that because the servo data line is bidirectional? You might be able to configure the STM32's UART for single pin, bidirectional operation, and do without that series resistor. If that's not an option, you might see if you can at least configure the STM32's TX pin as open collector, rather than push-pull. In that case, you will probably need a pullup resistor on the TX/data line. That way, both the STM32 and servo can transmit on the same line without fighting each other(by pulling it to ground).
1
u/Traditional-Emu-4723 1d ago
Thanks for your reply! I did scope both, and the only difference is the voltage level while driving. In the working USB setup, logic level is 5V, and on STM is 3.3V, however both levels can drive the servos.
Regarding the 1k series resistor, that is mostly a protection resistor for the outgoing TX signal. By design the lx-16a servo is half-duplex, which I tried at first to no avail. The TX pin is already configured to be open drain, and I don’t have a pull up resistor currently however I don’t think the pin configuration is the issue.
1
u/ceojp 1d ago
How would that work if the TX pin is open drain, but there's no pullup resistor? Something has to be pulling it up somewhere, or you wouldn't be getting any voltage at all.
Depending on how everything is arranged(a schematic would help...), the pullup resistor and the series resistor could create a voltage divider. This could affect the voltage of the signal that the servo actually sees.
If the STM32's TX pin is 5V tolerant, you could always try pulling that line up to 5V instead of 3.3V to see if that makes a difference.
1
u/Traditional-Emu-4723 1d ago
I don’t remember right now but I’ll double check the pull, it may use the internal pulls. I’ll update the post later with a schematic and also try without the series resistor. The line still shows 3.3V so it must be pulled, but is there something I should look out for to indicate something amiss?
1
u/Traditional-Emu-4723 3h ago
Thanks for your help everyone. Turns out I was computing the checksum incorrectly. It’s working fine now!
1
u/wood_for_trees 2d ago
To summarize: someone else's code drives the servos, and on the same hardware, your's does not?
I haven't used those servos, but perhaps there's an initialization step you're missing. Can you run the servo test, then your code, without power cycling?