avrdude writing flash in raw binary format

Go To Last Post
2 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I am trying to understand the binary format of avr-objcpy,

In the man is written:

 objcopy can be used to generate a raw binary file by using an output target of binary (e.g., use -O binary).  
 When objcopy a raw binary file, it will essentially produce a memory dump of the contents of the input object file.  
 symbols and relocation information will be discarded.  The memory dump will start at the load address of the lowest
 section copied into the output file.

I tried it and the length of the file was 0x311e (exactly as the data size as I saw in .map file).

 

My question is how the avrdude knows what is the lowest address to start writing from?  - if the bin file size is 0x311e and the data to be written size is 0x311e, there are no room for "meta data".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is the exact reason people use formats like Intel Hex and Motorola Srecord. (apart from the fact that in the old days you could put the text of them in the body of an email!). It's because they DO hold position information. A binary file is just that, binary, so yoiu have to carry any information about where it should be placed separately.

 

Some programmer programs, when dealing with binary, allow for something like --addr=0x7E00 to be passed to say WHERE you want the binary to be written. As far as I can see there is no such option in avrdude. So if you want it to put the binary at a non-0 address do something like:

$ hexdump -C tiny.bin
00000000  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  04 98 97 00 01 20 03 3d  08 00 0a 20 02 30 d3 00  |..... .=... .0..|
00000020  64 20 02 18 69 00 c8 20  01 27 0f 00 01 6b 01 20  |d ..i.. .'...k. |
00000030  8c 04 b0 20 01 1a 09 05  dc 20 01 13 87 00 02 6b  |... ..... .....k|
00000040  01 07 cf 00 05 6b 01 03  e7 00 0a 6b 01 01 f3 00  |.....k.....k....|
00000050  14 6b 01 00 c7 00 32 6b  01 00 63 00 64 6b 01 00  |.k....2k..c.dk..|
00000060  31 00 c8 6b 01 00 13 01  f4 6b 01 00 09 00 01 4d  |1..k.....k.....M|
00000070  01 00 04 00 02 4d 01 00  02 0d 05 6b 01 00 01 00  |.....M.....k....|
00000080  05 4d 01 00 00 00 0a 4d  00 00                    |.M.....M..|
0000008a
$ avr-objcopy -I binary -O ihex --change-addresses=0x7E00 tiny.bin tiny.hex
$ cat tiny.hex
:107E00000100000000000000000000000000000071
:107E1000049897000120033D08000A200230D30097
:107E2000642002186900C82001270F00016B01209F
:107E30008C04B020011A0905DC2001138700026BB5
:107E40000107CF00056B0103E7000A6B0101F30096
:107E5000146B0100C700326B01006300646B01000A
:107E60003100C86B01001301F46B01000900014DE2
:107E700001000400024D0100020D056B010001002C
:0A7E8000054D010000000A4D00004E
:0400000300007E007B
:00000001FF

As you can see here the output Intel Hex file now has a base address of 0x7E00 which I achieved using --change-addresses.

 

If you now program this file using avrdude it will first set the destination to be 0x7E00 and THEN send the binary content.