next topic »

[on:]

I need to build a program loader that plays with the standard bootloaders but operates over a TCPIP network (encrypted or cleartext.)
The first steps indicate a mismatch between the IDE-generated hex files and the Intel hex format they presumably follow.

Fade.hex:

3A 31 30 30 30 30 30 30 30 30 43 39 34 36 31 30 30 30 43 39 34 37 45 30 30 30 43 39 34 37 45 30 30 30 43 39 34 37 45 30 30 39 35 0D 0A 3A 31 ...

Intel load format:

Record mark | Rec. length | offset | rectype | info/data | cksum
1-byte       1-byte       2-bytes 1-byte    n-bytes     1-byte
Each record begins with a RECORD MARK field containing 03AH, the ASCII code for the colon(':')

Notice that 0x31 is a record length (byte 1), but the next record starts earlier (next 0x3A).
I hope I'm wrong instead of the format and somebody can point out the error.

In this project I'm trying to stay away from specific hardware, but the basic foundation is a serial tunnel device such as the Ethernet shield.
I am testing some code borrowed from http://arduino.cc/forum/index.php/topic,46486.0.html
and it indicates that there are different bootloaders floating about - mucking about with the standard bootloader may just kill this project. I get different responses depending on whose 328p board I use.

[Reply #1 on:]

the IDE always generates correct intel hex files on my system.  Are you sure you're looking in the right place?

:1003700041304530423145303243393133304530F8
:10038000313139363843393145420A3A313037460E
:100390003130303031313937393045303938324603
:1003A00038383237383232423933324231323936E4
:1003B0004641303143350A3A3130374632303030F9
:1003C00030433031443742454538393531313234A4
:1003D000344535463546344646314530413033386C
:1003E00046390A3A313037463330303042463037BA
:1003F0003531463745303931303030324630393199
/tmp/applet1234/optifix.cpp.hex 14%

[Reply #2 on:]

Ahhhhhh thanks - I was trying to be too logical - so the format is
first character is a byte, all following are hex pairs forming a byte.

[Reply #3 on:]

Record mark | Rec. length | offset | rectype | info/data | cksum
1-byte       1-byte       2-bytes 1-byte    n-bytes     1-byte
Each record begins with a RECORD MARK field containing 03AH, the ASCII code for the colon(':')

so the format is first character is a byte, all following are hex pairs forming a byte.

Yes; the description you quote is a bit poorly worded.  I would say something like:

:10036000313037463030303035303931303130325D

Record mark | Rec. length  | offset       | rectype        | info/data      | cksum | newline
1 byte ':'  | 2 hex digits | 4 hex digits | two hex digits | n*2 hex digits | 2 hex digitis | crlf "\r\n" |
:           | 10           | 0360         | 00             | 3130..313032   | 5D            |

"optifix" posted elsewhere in the forums has code that parses/reads intel hex format data, BTW...

[Reply #4 on:]

Now that I have mind-melded with avrdude a bit more I might take this project in a slightly different direction; reinventing the wheel is not a good idea - I think all I need is a -P <tcpip port> option on avrdude.
Thanks for the parse pointer though - never know which way the chips will fall.
 

[Reply #5 on:]

I think all I need is a -P <tcpip port> option on avrdude.

Most operating systems have a utility floating around that will create a virtual serial or com port out of a TCP connection (with or without assorted protocols like telnet or ssh.)  It's been a while so I don't have any specific recommendations...