2
\$\begingroup\$

I am trying to understand the hex file generated by the AVR Studio. I wrote a code in assembly. The code is as follows:

#include "m328pdef.inc"
.org 33
rjmp reset
reset: 
        add r16,r17
main:
        out DDRB,r16
        rjmp main

The .org is to hard code my code into the memory location 33. Then I checked the generated hex file. That is as follows:

:020000020000FC
:0800420000C0010F04B9FECF5C
:00000001FF

The 2nd line should be of interest. The address where this is stored is 0042. How so? Can you kindly clarify my understanding please.

\$\endgroup\$
0

2 Answers 2

2
\$\begingroup\$

This is a standard format Intel hex file used by many manufacturers' linkers.

The first character is always ':'

The next two hex digits are the byte count, in two-digit pairs, in the data field of the line. So the first line has two bytes of data, the next eight bytes, and tghe last zero bytes.

The next four hex digits are the address, in bytes. Olin has already mentioned why the starting address of 33 (0x21) is display as 0042.

The next two hex digits are the record type. 02 is an extended address type, allowing addresses to extend beyond the 64K limit of the original format. But the data field following the 02 in the first line is 0000, so there really isn't any extension in this case.

The last two hex digits are the checksum (see the Wikipedia article for the calculation).

In the second line, the 00 record says there will be an address field (e.g. 0042) preceding the record type, and the eight bytes of data following the record type (00,C0,... thru CF).

The last line, with the record type of 01, is an end of record.

\$\endgroup\$
0
5
\$\begingroup\$

I don't know anything AVR binary, so this is a guess although it seems to fit very well.

You told it to start putting your code at 33, which is 21h. Addresses are probably doubled in the HEX file because the addressable word is wider than 8 bits, so that comes out to 42h. This should, of course, all be well documented in the linker or assembler manual.

\$\endgroup\$
4
  • \$\begingroup\$ Olin. Can I buy your brain please. \$\endgroup\$ Commented Apr 28, 2014 at 19:38
  • \$\begingroup\$ Olin, surprised you didn't recognize this format, PIC uses the same one for it's hex files. :) \$\endgroup\$
    – tcrosley
    Commented Apr 28, 2014 at 21:41
  • \$\begingroup\$ @tcrosley: I recognized the format just fine. In fact I copied and pasted the HEX file in the question into one of my utilities to interpret it and write out the bytes in a more readable form. This verified that the first byte is indeed at address 42h. What I am not familiar with is how the AVR tools use the standard HEX file, like addresses doubled or not or other conventions. The addresses are doubled for some PICs too, so that seemed a plausible explanation, but I don't know how wide addressable chunks of AVR instructions are, although apparently more than 8 bits. \$\endgroup\$ Commented Apr 28, 2014 at 21:45
  • \$\begingroup\$ I was just going by your comment "I don't know anything AVR binary". I shouldn't have questioned your PIC expertise. \$\endgroup\$
    – tcrosley
    Commented Apr 28, 2014 at 21:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.