avr-objcopy and EEPROM, removing 0x03 record.

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

I am trying to prevent avr-objcopy from inserting the "0x03 Record "Start Segment Address "" into the EEPROM file. (2nd from last line in the intel hex file)

If I have an application entry point in a program for the new AvrTiny1 series, which starts the app section after the bootloader, and I extract the eeprom using avr-objcopy, I can't seem to prevent the application section entry point info from getting into the EEPROM hex file..

I end up getting :0400000300000300F6 in both the application hex, and the eeprom hex.

For application hex the 0x03 record I have noticed will mimic the start address in the application hex file.

In the case of the eeprom the start address of hex data and 0x03 record value obviously are conflicting.

 

copied from a typical makefile, I have...

 

#create eeprom file from elf
$GCC/avr-objcopy -j .eeprom  --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0  --no-change-warnings -O ihex "$FM.elf" "$FM.eep"

 

:10000000FF010106020909FFFFFFFFFFFFFFFFFFDE
:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0
:0F002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
:0400000300000300F6 <--- how to remove this? eeprom entry point is not supposed to be 0x300, that is the application entry point
:00000001FF

 

any ideas on how to remove the 0x03 recorded at compile time would be appreciated.

 

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

--set-start=0

 

or some variation.  Try avr-objcopy --help , something in there will be the one.

 

Looking at objcopy.c and ihex.c in avr gcc sources (xc8), it looks like --set-start simply sets the start address to whatever you provide, and the intel hex producer simply emits an 03 record if the start address is not 0. Whether you specify a -j section, makes no difference as it is simply done (if not 0) before the eof record.

Last Edited: Sat. Oct 5, 2019 - 10:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I'll bite, why does it matter if the .hex has an 03 or not? What is it that is reading the hex that is upset by its presence? Perhaps that is the thing that really needs fixing here.

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

curtvm, thanks very much, --set-start=0 did the trick...

clawson, some hex tools that I use will throw an error if the 03 record exist and does not match the start address in the hex; they are some tools I wrote some time ago, but don't want to rewrite them. most other tools do ignore the 03 record as far as I know. It also bothered me because if the 03 record exist, it should be zero, and not the entry point of the application, just it being inside the hex file was an annoyance, and it being a value that was not expected was another annoyance.

Last Edited: Sun. Oct 6, 2019 - 03:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The tools are wrong if they can't handle all ihex records.

 

Can't you just use Python or sed to modify the .hex to remove lines with 03?

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

>The tools are wrong if they can't handle all ihex records.

 

Related, but less important-

the Intel hex format has a record mark to indicate the start of a record, and a record length field to indicate how long the record is. Easy and simple. But, if you search for any info on the format, you will conclude that the records are line based (Keil, Arm, etc., all seem to think so). There is no white space involved in a hex record, so there is no need to be looking at anything other than what is inside a record. Anything not in a record should be of no concern to any parser of a hex file. If records were required to be separated by lines as they think, there would have been no reason for a record mark and length. It is an easy format- find a record mark, get its length, process record, find next record mark, repeat.

 

Some examples using avr-objcopy-

 

ok-
:0100000000FF
:00000001FF

if you want comments

put them after eof record

 

fail-
my eeprom
:0100000000FF
:00000001FF

 

ok-
:0100000000FF:00000001FF

 

fail- (leading space)
 :0100000000FF:00000001FF

 

fail-
:0100000000FF :00000001FF

 

 Like I said, unimportant, but interesting how such a simple format somehow evolved to requiring specific white space. Since it makes sense to output the hex file as lines of records for readability, somehow that changed into a requirement.

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

12oclocker wrote:

I am trying to prevent avr-objcopy from inserting the "0x03 Record "Start Segment Address "" into the EEPROM file. (2nd from last line in the intel hex file)

If I have an application entry point in a program for the new AvrTiny1 series, which starts the app section after the bootloader, and I extract the eeprom using avr-objcopy, I can't seem to prevent the application section entry point info from getting into the EEPROM hex file..

I end up getting :0400000300000300F6 in both the application hex, and the eeprom hex.

For application hex the 0x03 record I have noticed will mimic the start address in the application hex file.

In the case of the eeprom the start address of hex data and 0x03 record value obviously are conflicting.

 

copied from a typical makefile, I have...

 

#create eeprom file from elf
$GCC/avr-objcopy -j .eeprom  --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0  --no-change-warnings -O ihex "$FM.elf" "$FM.eep"

 

:10000000FF010106020909FFFFFFFFFFFFFFFFFFDE
:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0
:0F002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
:0400000300000300F6 <--- how to remove this? eeprom entry point is not supposed to be 0x300, that is the application entry point
:00000001FF

 

any ideas on how to remove the 0x03 recorded at compile time would be appreciated.

 

 

If this helps any, here's the way I use avr-objcopy in my standalone Makefiles:

 

%.hex: %
        @${OBJCOPY} \
        -O ihex \
        -R .eeprom \
        --preserve-dates \
        ${<} ${@}

%.eep: %
        @${OBJCOPY} \
        -O ihex \
        -j .eeprom \
        --preserve-dates \
        --no-change-warnings \
        --change-section-lma=.eeprom=0 \
        --set-section-flags=.eeprom=alloc,load \
        ${<} ${@}

%.lst: %
        @${OBJDUMP} \
        --demangle \
        --disassemble \
        --source \
        --wide \
        ${<} > ${@}

 

Of course, "${OBJCOPY} is "avr-objcopy" and likewise for OBJDUMP.

 

Hope this helps.

Gentlemen may prefer Blondes, but Real Men prefer Redheads!