0

I am trying to understand a very simple assembly to hex conversion.

This is the assembly code for AVR:

Assembly Code 

ldi R17, 20

and corresponding

Hex code 

:020000020000FC..:0200000014E109..:00000001FF..

Now this is how I add delimiters:

[:] [02] [0000] [02] [0000FC..:0200000014E109..:00000001] [FF]..

Here is how I am interpreting it: 

  [:]:  start of the record 
  [02]: Size of the code  (seems correct as I am having only one LDI instruction)  
  [0000]: start address 
  [02]: End address 
  [0000FC..:0200000014E109..:00000001]: Code  (This is not clear to me)   
  [FF]: Check sum

I would like to know if I have put delimiters at right places.

Secondly why I am getting

..

And finally I am unable to understand how the middle 'code' section equivalent to the LDI instruction I have used.
Any pointers in this regard is appreciated. Thanks

Update

I now understand much better thanks to the discussions below. In code section I can see 14E1 which is equivalent of LDI. But what are the other code in this section ?

[0000FC..:0200000014E109..:00000001]:

user3891236
  • 607
  • 1
  • 9
  • 23
  • Do you know what an [Assembler](https://en.wikipedia.org/wiki/Assembly_language#Assembler) does? – Ajay Brahmakshatriya Oct 04 '17 at 04:36
  • Do AVR assemblers output this hex format for feeding to a flash ROM programming tool? Most assemblers (for other platforms) output object files (`.o`) containing binary machine code, not a hexdump of it. – Peter Cordes Oct 04 '17 at 04:38
  • What machine code did you expect from `ldi` when you looked it up in the instruction reference manual? – Peter Cordes Oct 04 '17 at 04:39
  • @PeterCordes Yes. I always get such hex files. – user3891236 Oct 04 '17 at 04:39
  • PeterCordes , yes LDI translate instruction as given here http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_LDI.html – user3891236 Oct 04 '17 at 04:40
  • Yes, exactly. So you should probably say in the question that you'd expect to see `E1` `14` in the machine code, if I have that right. I see a `14E1`, so I guess there's an endianness issue. – Peter Cordes Oct 04 '17 at 04:43
  • You should also include in the question the full source of the text input to the assembler (if that isn't it), and the command you ran. – Peter Cordes Oct 04 '17 at 04:46
  • Should it not be E134: 1110 KKKK dddd KKKK = 1110 0001 0011 0100 – user3891236 Oct 04 '17 at 04:47
  • @PeterCordes since d= 0x11 – user3891236 Oct 04 '17 at 04:48
  • @user3891236 the encoding says 16 <= d <= 31. Which means means 16 is subtracted from 0x11 before storing, hence 1. – Ajay Brahmakshatriya Oct 04 '17 at 04:51
  • 2
    Also if d was 0x11, how would it be stored as 0011 ? that would be 0x3. – Ajay Brahmakshatriya Oct 04 '17 at 04:51
  • @AjayBrahmakshatriya Ok. got it. But how you are interpreting 16 <= d <= 31( means 16 is subtracted from 0x11) is not clear to me – user3891236 Oct 04 '17 at 04:53
  • @AjayBrahmakshatriya How exactly we treat: dddd ? – user3891236 Oct 04 '17 at 04:56
  • @user3891236 since the value of d can be only from 16 to 32, there is no point in storing a 2 nibble number (numbers above 16 require more than a nibble). Hence only a number from 0-15 is stored and 16 is automatically added to it. – Ajay Brahmakshatriya Oct 04 '17 at 04:56
  • 2
    dddd is 4 bits of d, which means that d can be atmost 15. and in case of 1 (17 -1) it will be 0001. It is not represented here in hex but in binary. – Ajay Brahmakshatriya Oct 04 '17 at 04:57
  • 2
    @AjayBrahmakshatriya Ok. Got the point. But in code section I see more data than 14E1( which is my one line code) Why so? . Could you please elaborate it as an answer to this question? – user3891236 Oct 04 '17 at 05:00
  • @PeterCordes Thanks. I see now. Please tell me i code section what all is there apart from 14E1? – user3891236 Oct 04 '17 at 05:05
  • @user3891236 that I am unaware of. You need to check the documentation of your assembler. My assembler generates `.o` files. – Ajay Brahmakshatriya Oct 04 '17 at 05:09
  • @user3891236: If I knew the answer, I would have just answered it. You still haven't posted the full source and the command you used to assemble. (Or a link to the documentation for the assembler software you used). But I upvoted it anyway in case someone that develops for AVR recognizes this from using the same tools. – Peter Cordes Oct 04 '17 at 05:51

1 Answers1

2

You seem to be missing the important point that each line of the Intel HEX file is a new record. Every record has a colon at the beginning and a newline marking at the end. You seem to think that the data section of your record is 0000FC..:0200000014E109..:00000001 but actually that looks like segments from three different lines. Did you open this in a hex editor? Hex editors often display newline and carriage return characters as periods. Do not open HEX files in a hex editor because hex editors are designed for editing binary files, not text files. A hex file is a text file that you can open in Notepad, Emacs, or any standard plain text editor.

Let's look at one of the records you posted:

:0200000014E109

The Intel HEX Wikipedia article tells us how to interpret this record:

  • 02: Byte count
  • 0000: Start address
  • 00: Record type is data
  • 14E1: The two bytes of data
  • 09: Checksum

To help interpret the two bytes of data, you need to look at Atmel's AVR Instruction Set Manual. Note that the instructions are stored in Little Endian order in the flash, so 0xE1 is actually the most significant byte of the word, and if you wrote the word in binary it would be:

1110 0001 0001 0100

Note that not all data in flash has to be AVR instructions: you can store arbitrary data in there too.

David Grayson
  • 84,103
  • 24
  • 152
  • 189
  • Your answer is quiet satisfactory. just one thing. Can I assume the other records are corresponding to various libraries that I included in my code? Right ? I am not bothering about those since I wanted to specifically see the low level code corresponding to the assembly code that I have written myself. So I am wondering how these other records came ? – user3891236 Oct 09 '17 at 03:49
  • No, the first record sets the high bytes of the address and the last record indicates the end of the file. – David Grayson Oct 09 '17 at 12:54