[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-gcc-list] avr-objdump 2.11 gives illegal Intel Hex

From: Bryce Denney
Subject: [avr-gcc-list] avr-objdump 2.11 gives illegal Intel Hex
Date: Thu, 13 Jun 2002 03:44:10 -0400 (EDT)

I upgraded to the most recent uisp version from May 24 and now I'm having
trouble reading certain Intel HEX files.  I think the intel hex file is
the problem, but I'm not an expert in such things.  Uisp doesn't like the
fact that the input file has one record with type 3.

My build process is to assemble, then link to an ELF file, then use
avr-objcopy to produce ihex.  For example,

avr-gcc -mmcu=atmega163 -Wa,-ahlms=out.lst -Os -I. -c main.c
avr-gcc -mmcu=atmega163 -Wa,-ahlms=out.lst -Os -I. -c serial.c
avr-gcc -mmcu=atmega163 -Wa,-ahlms=out.lst -Os -I. -c assembly.S
avr-gcc -mmcu=atmega163 -Wl,-Map=out.map  -L. main.o serial.o assembly.o
main.lcf -o main.elf
avr-objcopy -O ihex main.elf main

Versions: avr-gcc 3.0, avr-objcopy 2.11

Then I look at the intel hex output file, called main, and the next to
last line looks very suspicious.

:0400000300003C00BD       <---this one

The line that starts with 04 decodes as follows:
target address=0x0000
record type=0x03   (valid record types are 0,1,2. What's 3?)
data=00 00 3c 00

For comparison purposes, if I make a Motorola SREC instead, I don't see
anything strange.  Uisp accepts the SREC and it works.

Motorola SREC equivalent:

At the risk of jumping to conclusions, it looks to me like avr-objcopy has
a bug in its Intel HEX output code.  Any other theories?  Is this a known
problem in binutils?


avr-gcc-list at http://avr1.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]