by StuartL » Fri Apr 18, 2008 7:51 am
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.