I browsed all the resources I could find on the Web, such as Kekoa Proudfoot's RCX Internals, his firmdl 'C' download program and his download-trace file, Dave Baum's 'NQC' program, and Russell Nelson's Lego Mindstorms Internals to try and get some advice on writing a firmware download program.
But it wasn't until Kekoa gave me this excellent recipe for the download process that I was able to start.
You can view the program text and you can then save the file as (say) firmwdl.bas and run it under QBasic. You will need to edit the line which chooses the serial port if you don't want to use COM1. Or if you compile it to an EXE file you can use a command line argument to choose the port.
If you haven't got a QuickBasic compiler and you really need the EXE version, download it from here.
written by Kekoa Proudfoot in the Lego Mindstorms mail list Jan 1 1999
and quoted here with permission
Here is an explanation of the download process:
I assume you know the basic packet protocol. If not, it was described by
Dave Baum, you can see his description here:
http://graphics.stanford.edu/~kekoa/rcx/protocol.html
Step 1: Read in the s-record file
See http://graphics.stanford.edu/~kekoa/rcx/s-record.txt for a
description of the format that somebody else wrote up.
After this, you should have an image with a starting address and an
ending address.
If you like, search from the ending address backward until you find the
first non-zero byte, and make that the new ending address. This is not
entirely legal, because maybe that data was supposed to be set to zero,
but it speeds downloading, and it works with the supplied Firm0309.lgo.
Step 2: Find the checksum of the image
Add up the bytes between the starting and ending address. You checksum
should be an unsigned short. A short has 16 bits.
Step 3: Send a delete firmware message
In hex, the data in the message should be:
65 01 03 05 07 0b
You need to supply the header, complement, and checksum bytes.
Step 4: Send a start firmware download message
In hex, the data in the message should be:
75 00 80 dd cc 00
cc is the most significant byte of the image checksum
dd is the least significant byte of the image checksum
Step 5: Send the image data using transfer data messages
Break up the image into 200 byte chunks.
Loop over the chunks. Compute the checksum for the current chunk by
adding up the bytes of the current chunk. This checksum should be a
byte, not a short.
For each chunk, send a message with the following data (in hex):
xx bb aa dd cc databytes ee
xx is the message opcode
aa is the most significant byte of the index of this chunk
bb is the least significant byte of the index of this chunk
cc is the most significant byte of the size of this chunk
dd is the least significant byte of the size of this chunk
databytes are the data bytes in this chunk
ee is the checksum byte of this chunk
The opcode should alternate between 45 and 4d with every other chunk
The index should start at 1 and increase by 1 with each successive chunk
The last chunk should have an index of 0
Step 6: Send an unlock firmware message
In hex, the data in the message should be:
a5 4c 45 47 4f ae
That's it.
Sending messages is non-trivial. First you have to configure the serial
port. Then, when you send a message by writing data to the serial port,
you have to wait for a proper reply to make sure the rcx received it. If
you do not receive a proper reply, send the exact same message again until
you do hear a proper reply.
For more information on messages and the serial protocol, see:
http://graphics.stanford.edu/~kekoa/rcx/#Serial
http://graphics.stanford.edu/~kekoa/rcx/opcodes.html
With all of this in mind, the following download trace should make sense:
http://www.crynwr.com/lego-robotics/trace1.txt
A few things to note about the trace:
- opcodes alternate between having the 0x08 bit set and clear
- the apparent RCX echo is really the caused by the IR tower
- the trace includes some extra commands (10,18) that aren't strictly needed
Kekoa Proudfoot
Jan 1 1999
|
All Trademarks acknowledged