We now have the opportunity to share/review our understandings on Intel-hex Formatted File.
Intel-hex formatted file indeed is a transmission file. It is made out of the object file for onward
transmission of the 'Binary Codes/Data' of the application program into the target controller.
The digits (every 4-bit) of the Source Object file are converted into ASCII codes which are included in
the Intel-hex file. The Intel-hex file contains few pre-amble and post-amble bytes to make a
successful transmission session.
An Intel-hex file is composed of many frames. A frame is composed of many fields. The names and
meanings of the fields of an Intel-hex frame:
: 04 2000 00 8B 47 7F F4 82 ; mov ax, WORD PTR ds:[bx+7Fh; hlt (8086)
(a) (b) (c) (d) (e) (f)
Field-(a) - Start Code: It indicates the beginning of the transmission of a frame. The receiver looks
for this character in order to synchronise with the transmitter.
Field-(b) - Byte Count: In indicates the number of data bytes contained in Filed-(e).
Field-(c) - Address: In indicates the address of the memory location (for Real Mode 80x86 it is a
byte organised RAM location with physical address 0000:20000) into which the
1[sup]st[/sup] data byte (8B) will be stored.
For AVR, the interpretation is a bit different:
If the given frame would belong to an AVR, the value 2000 would be divided by two
by the receiver to get the address (1000) of the memory location of the word organised
flash into which the 16-bit data (478B not 8B47) would be stored.
Field-(d)- Record Type: It indicates, when 00, transmission of normal data bytes. There are still
frames to transmit. If the Record Type is found as 01, the receiver understands that
there is the end of transmission session.
Field-(e) - Data: This field contains actual data.
Filed-(f) - CHKSUM: All the bytes of the frame are added except Field-(a). The carry is discarded.
Two's compliment of the remaining byte is formed; it is transmitted as the last byte
of the frame. It can be used check the validity of the received frame and instruct the
transmitter to re-send the frame, if required.
- Let us now analyse the Intel-hex frame submitted by drdavros
: 04 0000 03 00007E00 7B
(a) Because Fuse Settings (EF = 0x05, HF=0xDE, LF=0xFF) of ATmega328 of ArduinoUNO,
the control begins at location 0x3F00 of the Flash Memory. The Boot Loader program
had been pre-stored starting from this location. The Boot Loader writes the incoming
code/data into the application flash (0x0000 - 0x0040; 0x0041 - 0x3EFF).
(b) As westfw has indicated, this frame is ignored due to 'non-data' record field. There
is evvidence in favor of it:
.include 'mdef32.inc" ; List Codes
rjmp 0x0040 ; 0000 - C03E
.org 0x0040 ;
ldi r17, 0x5F ; 0040 - E51F
:02 0000 02 0000 FC ; Receiver either ignores it or it is over-written by the next frame
:02 0000 00 3FC0 FF ; My receiver always checks if it is 00 or 01.
:02 0080 00 1F E5 7A
(c) drdavros is being requested to post the next frame of the
optiboot in order to enable us to see what information is there.
- Thanks to drdavros for the very uncommon but very interesting post.