Legacy Forum: Preserving Nearly 20 Years of Community History - A Time Capsule of Discussions, Memories, and Shared Experiences.

Using Zigbees and serial cables for Linux firmware upload

Bioloid robot kit from Korean company Robotis; CM5 controller block, AX12 servos..
4 postsPage 1 of 1
4 postsPage 1 of 1

Using Zigbees and serial cables for Linux firmware upload

Post by StuartL » Fri Apr 18, 2008 7:51 am

Post by StuartL
Fri Apr 18, 2008 7:51 am

Last night we spent a long time decoding and testing firmware upload using both the serial cable and zigbees from Linux. Once we figured out how it worked it's actually surprisingly easy.

First things first: The upload of firmware through the robot terminal is literally just the binary software image dumped into flash offset 0. The checksum is sent as the last char of the firmware and is also written to flash because there's no harm in it not being written. This appears to be calculated on the fly by the Robot Terminal.

Secondly the compiler makefile by default creates an Intel format .hex file which Robot Terminal converts into the binary file. Anyone with the power of google can figure out how to either make the makefile create the .bin directly or convert the hex to bin with a wide variety of commonly available tools.

So the method of getting a firmware image onto the CM-5 from anything other than Robot Terminal is as follows:

- Send hashes to get the prompt. If you're scripting this (as we are) just wait for hashes to be sent back down the serial cable.
- Send a carriage return (0x0d) to get to the next prompt.
- Send an 'l<cr>' to start the upload.
- Wait for the 'ready' signal.
- Wait for a short period for the CM-5 to be ready (it doesn't appear to work straight away).
- Send the binary image you wish to upload, adding together each byte as you go. Make sure you send slow enough not to overrun the CM-5 buffers. We were testing with 100us of delay per byte which seemed to work.
- Send the checksum character you calculated in the last step.
- Confirm the checksum is correct.

The last step is absolutely critical, especially when using Zigbee. We've found that even under ideal conditions the Zigbee does NOT reliably send characters back and forth. It works most of the time but the larger the image the more chance of one of the bytes going missing. Therefore when doing firmware uploads via Zigbee you MUST check that the checksum is correct otherwise it'll just crash at some point in your software, usually the beginning.
Last night we spent a long time decoding and testing firmware upload using both the serial cable and zigbees from Linux. Once we figured out how it worked it's actually surprisingly easy.

First things first: The upload of firmware through the robot terminal is literally just the binary software image dumped into flash offset 0. The checksum is sent as the last char of the firmware and is also written to flash because there's no harm in it not being written. This appears to be calculated on the fly by the Robot Terminal.

Secondly the compiler makefile by default creates an Intel format .hex file which Robot Terminal converts into the binary file. Anyone with the power of google can figure out how to either make the makefile create the .bin directly or convert the hex to bin with a wide variety of commonly available tools.

So the method of getting a firmware image onto the CM-5 from anything other than Robot Terminal is as follows:

- Send hashes to get the prompt. If you're scripting this (as we are) just wait for hashes to be sent back down the serial cable.
- Send a carriage return (0x0d) to get to the next prompt.
- Send an 'l<cr>' to start the upload.
- Wait for the 'ready' signal.
- Wait for a short period for the CM-5 to be ready (it doesn't appear to work straight away).
- Send the binary image you wish to upload, adding together each byte as you go. Make sure you send slow enough not to overrun the CM-5 buffers. We were testing with 100us of delay per byte which seemed to work.
- Send the checksum character you calculated in the last step.
- Confirm the checksum is correct.

The last step is absolutely critical, especially when using Zigbee. We've found that even under ideal conditions the Zigbee does NOT reliably send characters back and forth. It works most of the time but the larger the image the more chance of one of the bytes going missing. Therefore when doing firmware uploads via Zigbee you MUST check that the checksum is correct otherwise it'll just crash at some point in your software, usually the beginning.
StuartL
Savvy Roboteer
Savvy Roboteer
Posts: 350
Joined: Mon Jun 04, 2007 3:46 pm
Location: Thatcham, Berkshire, UK

Post by StuartL » Wed May 21, 2008 2:00 am

Post by StuartL
Wed May 21, 2008 2:00 am

Slight update to this, the Zigbee seems to be very sensitive to interference, especially cables and metalwork near the transceivers. If you're having reliability issues with the Zigbee try to move any metalwork away from near the communication path.
Slight update to this, the Zigbee seems to be very sensitive to interference, especially cables and metalwork near the transceivers. If you're having reliability issues with the Zigbee try to move any metalwork away from near the communication path.
StuartL
Savvy Roboteer
Savvy Roboteer
Posts: 350
Joined: Mon Jun 04, 2007 3:46 pm
Location: Thatcham, Berkshire, UK

Post by limor » Sat May 24, 2008 9:56 am

Post by limor
Sat May 24, 2008 9:56 am

have you tried using Gtkterm which i think will prompt you for a file when you enter the "load" comand. if i recall, CM5 bootloader was using the xmodem protocol
have you tried using Gtkterm which i think will prompt you for a file when you enter the "load" comand. if i recall, CM5 bootloader was using the xmodem protocol
limor
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1845
Joined: Mon Oct 11, 2004 1:00 am
Location: London, UK

Post by StuartL » Sun May 25, 2008 7:24 am

Post by StuartL
Sun May 25, 2008 7:24 am

It's not xmodem, it's just a binary transfer with a checksum byte at the end.

I know only because I sniffed the communication from the original Robot Terminal :)
It's not xmodem, it's just a binary transfer with a checksum byte at the end.

I know only because I sniffed the communication from the original Robot Terminal :)
StuartL
Savvy Roboteer
Savvy Roboteer
Posts: 350
Joined: Mon Jun 04, 2007 3:46 pm
Location: Thatcham, Berkshire, UK


4 postsPage 1 of 1
4 postsPage 1 of 1