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

[Bryce Denney]

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.

[snip]
:103F50001DD0F72FE62F192E082E21E027BFE89558
:103F6000FFFF000013D012D0F92FE82F60FD67BFCC
:103F7000C895802DE395C895902D089507D0082EFB
:0E3F800019E017BFE895FFFF000000D008957C
:0400000300003C00BD       <---this one
:00000001FF

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

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:
[snip]
S1133F501DD0F72FE62F192E082E21E027BFE89554
S1133F60FFFF000013D012D0F92FE82F60FD67BFC8
S1133F70C895802DE395C895902D089507D0082EF7
S1113F8019E017BFE895FFFF000000D0089578
S9033C00C0

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?

Thanks,
Bryce

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