- this dates back a few weeks, but I forgot to publish it! -
The updated firmware guide is available on the documentation wiki!
Recently, I got reports of USB2AX units that did not function properly with Robotis' Dynamixel wizard. Those were brand new units, and multiple simultaneous hardware failures seemed unlikely. Time to investigate.
On my computer, nothing strange, as always, the famous "It works for me" syndrome. However, I noticed that a RoboPlus update was available, and, thinking nothing of it, I started downloading it while searching for a way to repeat the problem at home.
As you might have already guessed, the new version of RoboPlus turned out to be the trigger element, and what is comes down to is the addition of support for Dynamixel PROs.
It appears that the Dynamixel PRO line uses a different protocol named Dynamixel 2.0. This protocol is more complex than DXL 1.0, with more header bytes (4!), longer adresses (2 bytes) and longer CRC (2 bytes), and a lot of new commands and cool features.
The fun thing with the Dynamixel Wizard is that even when you want it to search for DXl 1.0 devices, it sends a DXL 2.0 broadcast ping. And this ping looks like a DXL 1.0 packet addressed to 0xFD (the id used by the USB2AX), with a length of 0 bytes (which does not play well with DXL 1.0 as it's supposed to be >= 2), and a command ID of 0xFE.
As Murphy's law dictates, this ping 2.0 just so happened to fall in what seems to be the only place in the USB2AX parsing state machine where it could be stuck... which explains that after that, nothing would work anymore.
This is a good reminder why testing inputs with fuzzing techniques and trying to make completely fool-proof input parsing code is important. Luck has it that something will always happen to your program fail even when it is very unlikely.
