L'Hexapod: Bug in v7.0 of the servo controller firmware

Previously published

This article was previously published on lhexapod.com as part of my journey of discovery into robotics and embedded assembly programming. A full index of these articles can be found here.

The simple servo sequencer that I’ve been working on has exposed a bug in the servo controller firmware. The bug is due to stack corruption during movement completion notifications, so it only happens if you use the ‘multi-move’ commands or the delay move command. The problem is that at the end of SerialSendMoveCompletionNotification we jump back to the serial data accumulation loop rather than using a ret to return… Since we enter SerialSendMoveCompletionNotification via a call rather than a jump we are failing to balance the stack and so eating two bytes each time we call the function. Eventually the stack usage will start to overwrite our data space and cause ‘strangeness’. The fix is simple, remove the jump and replace it with a ret.

The sequencer has also exposed an issue which I think lies with my current servos. After continuous ‘stepping’; i.e. running the single leg as if it were walking for around 40-50 commands (15 steps), some of the servos start to slow down, there doesn’t seem to be anything wrong with the servo controller as the TextStar Serial LCD Display in “Servo monitor mode” was showing that the signals were still good and my multimeter showed that the servos weren’t trying to pull too much power. It seems to be a torque or heat issue; more investigation is required, but things seem fine if I’m just running servos that don’t have a load on them…