On Thursday we excitedly hurried into our workspace with a newly-arrived package. We had just received a box from Chris, our hardware engineer, containing two prototype stepper motor controller boards with a pair of motors. While we have been driving a servo with a bread-boarded controller, we had not yet been able to test our stepper motor code with actual hardware. After attaching an ESP-12 to the board and verifying that the chip was functioning correctly, we connected our Raspberry Pi’s UART pins to the TX\RX of the ESP and loaded our firmware onto the device.
It didn’t work. Our stepper motor wouldn’t move. We realized that the pin assignments we had used in our configuration header file was out of date and we were stepping to the wrong pin! We corrected our settings, recompiled and re-flashed the ESP.
It didn’t work. Our motor sputtered and swerved wildly while executing commands, sometimes making massive 45 degree jumps before alternating direction with every step, preventing any meaningful movement. The number of steps made didn’t correspond with the commands we had sent. At this point, Kyle had decided that there must have been an issue with the power supplied to the board, theorizing that the ground noise of the 12V power supply was interfering with the motor. After using a different power supply and getting the same results, we decided to make some diagnostic changes to the code to see if we were sending the correct signals to the correct pins. We recompiled and attempted to re-flash.
It didn’t work. In fact, it wouldn’t even flash the ESP. At first we thought the ESP was broken, but it would still boot and respond to our commands. We noticed that we weren’t seeing any serial communications with the device using minicom. We hooked up our servo prototype. No serial activity, no flashing ability. Horrified, we realized that we had fried the UART of our Raspberry Pi. We have no idea how, but we destroyed our development environment’s ability to deploy code!
After wallowing in crushing defeat, we finally managed to contact our hardware engineer. He told us we wired the motor up wrong. The board has 4 ports: A1, A2, B1, B2. The stepper motor has two wire pairs, and we assumed one pair was to get A and the other was to use B. It turns out that each pair needs an A and a B. Oops. We fixed the wiring and our stepper motor code and controller worked like a charm!
We now have a working prototype for our flagship WiFi motor, with servo motor controller prototypes on the way. Too bad we need to figure out another way to deploy firmware. Perhaps we can use other GPIO pins as a fake UART? Or maybe we’ll just bite the bullet and get FTDI USB-to-3.3V-serial converters.