EEprom file, how it's formatted

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

Hi Folks,

With Avr studio i'm making a eeprom file for an external i2c eeprom.
After Building the asm data code, the intel hex file looks like the picture below.
It's clear to me that the green, dark blue and purple are the data parts.
Now i trying to find out how the blue index (if it's an index) is formatted.
The 03 is the number of data lines, but the rest of this part is not clear to me.

Rest of the hex file is intel stuff, not that important now.

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

Simply google for "Intel hex file".

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Maybe my question isn't clear, but i don't think it has something to do with "intel hex file" but more with how it's compiled.

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

Edje11 wrote:
Maybe my question isn't clear, but i don't think it has something to do with "intel hex file" but more with how it's compiled.

And what do you mean by that? So did you google or not for "intel hex file" and got enlightened how the file format describes the contents of the memory? Even WikiPedia has an entry on Intel Hex file format.

- Jani

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

You have located your data into CSEG space (flash) and therefore in 2 bytes chunks, if the number of bytes are odd the last word will be padded with 0x00.

Put you data into ESEG for single byte format. The last byte of each line is the checksum.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

It seems pretty clear to me.

You are assembling 3 words with DW which are stored little endian.
Followed by the blocks of bytes with DB which are stored consecutively.

You would get the same intel hex file if the data was stored in FLASH or SRAM.

You would also get the same if you used ANY little-endian CPU that has no alignment restrictions.

Note that the DW arguments are the address of your byte table. Alter the .ORG and you will get different values in the DW section.

I would suggest that you write several assembler files , assemble and look at the listing file. So you can see the difference between moving the .ORG of your .DW ops and the .ORG of your .DB ops.

The listing file should be easy to read. Now compare the listing file to the intel hex file. You will observe how the intel hex file specifies the number of bytes in the record, the load address, the record type, the bytes, the checksum.

I have never programmed an i2c eeprom via STK500 but I can imagine that a intel hex file would be the same as any other regular intel hex file. If you exceed 64k bytes then you would need extended intel hex records. I have used 24C512 parts but one day a 24C1024 part may be produced.

David.

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

Thanks David,
now it's clear to me.