Searching \ for 'Info needed on Hex file formats.' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=info+needed+hex
Search entire site for: 'Info needed on Hex file formats.'.

Truncated match.
PICList Thread
'Info needed on Hex file formats.'
1997\06\02@205713 by Darren Humphrey

flavicon
face
Can anyone point me to info on the format for the various hex file
formats-Intel, Motorola, etc?

I'm trying to put together a set of tools for PIC development on UNIX
systems, and so far I've got apples and oranges all around.

I've got PICASM which generates two different Hex output types, PICSIM
which uses another input type, and PIC_CC, a C compiler which generates
Parallax output (which PICASM won't read).  And I have two Linux based
programming packages that I haven't tried yet so I don't know what they
want. (and don't appear to recognize the Don Mackenzie programmer).

I hope to eventually have a straight path from C compiler -> assembler
-> simulator -> programmer, all free and all with source code.

Any help is appreciated.

Darren

1997\06\03@061354 by Rick Miller

picon face
Hi Darren,

I wish I'd have kept all the stuff I got when I was in the same boat...
looking for info for building free PIC development tools.  If I remember
right, the format of the HEX file is detailed pretty extensively on
Parallax's site (http://www.parallaxinc.com, I think) "somewhere".  Could you be
sure and relay that info to the PICLIST when you've got it?

I'm going to re-organize the GNUPIC archive into pointers to individual
developers' pages as well as an archive of just such information that
developers would need to write PIC tools...  That info would be handy, and
if you're going to put any of your stuff (even preliminary info) up on the
web I'd love to make a link to it.

spam_OUTRick.MillerTakeThisOuTspamLinux.org
(keeper of the freshly-resurrected GNUPIC Archive)

1997\06\03@101554 by Ted Linn

flavicon
face
On June 2,  Darren Humphrey wrote:

{Quote hidden}

The Microchip Mpasm Users guide discusses three of these formats in appendix
A.  The users guide is available in pdf format from Microchip's web site.
If you want, let me know and I will email the relevant information directly
to you.


Ted Linn
Assistant Research Engineer
Research Instruments Group
Penn State University
333 Whitmore Lab
University Park,  Pa.  16802

1997\06\04@001856 by Paykar Chamani

flavicon
face
part 0 4666 bytes
Attached is a Microchip text about their different Hex file format.

Paykar

Ç Intel Hex Format (.HEX)

This format produces one 8-bit hex file with a low byte, high byte combination. Since each address can only contain 8 bits in this format, all addresses are doubled. This file format is useful for transferring PIC16/17 series code to PRO MATE"II, PICSTART" and third party PIC16/17 programmers.
Each data record begins with a 9 character prefix and ends with a 2 character checksum. Each record has the following format:

:BBAAAATTHHHH....HHHCC

where
BB - is a two digit hexadecimal byte count representing the number of data bytes that will appear on the line.
AAAA - is a four digit hexadecimal address representing the starting address of the data record.
TT - is a two digit record type record type that will always be '00' except for the end-of-file record, which will be '01'.
HH - is a two digit hexadecimal data byte, presented in low byte, high byte combinations.
CC - is a two digit hexadecimal checksum that is the two's complement of the sum of all preceding bytes in the record.

Example

<file_name>.HEX

       :1000000000000000000000000000000000000000F0
       :0400100000000000EC
       :100032000000280040006800A800E800C80028016D
       :100042006801A9018901EA01280208026A02BF02C5
       :10005200E002E80228036803BF03E803C8030804B8
       :1000620008040804030443050306E807E807FF0839
       :06007200FF08FF08190A57
       :00000001FF
-----------------------------------------------------------------------------------------------------------------

8-Bit Split Format (.HXL/.HXH)

The split 8-bit file format produces two output files: .HXL and .HXH. The format is the same as the normal 8-bit format, except that the low bytes of the data word are stored in the .HXL file, and the high bytes of the data word are stored in the .HXH file, and the addresses are divided by two. This is used to program 16-bit words into pairs of 8-bit EPROMs, one file for Low Byte, one file for High Byte.

Example

<file_name>.HXL

       :0A0000000000000000000000000000F6
       :1000190000284068A8E8C82868A989EA28086ABFAA
       :10002900E0E82868BFE8C8080808034303E8E8FFD0
       :03003900FFFF19AD
       :00000001FF

<file_name>.HXH

       :0A0000000000000000000000000000F6
       :1000190000000000000000010101010102020202CA
       :100029000202030303030304040404050607070883
       :0300390008080AAA
       :00000001FF

-----------------------------------------------------------------------------------------------------------------

32-Bit Hex Format (.HEX)

The extended 32-bit address hex format is similar to the hex 8 format described above, except that the extended linear address record is output also to establish the upper 16 bits of the data address.  This is mainly used for 16-bit core devices since their addressable program memory exceeds
32 k words.
Each data record begins with a 9 character prefix and ends with a 2 character checksum. Each record has the following format:

       :BBAAAATTHHHH....HHHCC

where
BB - is a two digit hexadecimal byte count representing the number of data bytes that will appear on the line.
AAAA - is a four digit hexadecimal address representing the starting address of the data record.

TT - is a two digit record type:

               00 - Data record

       01 - End of File record

               02 - Segment address record

       04 - Linear address record

HH - is a two digit hexadecimal data byte, presented in low byte, high byte combinations.
CC - is a two digit hexadecimal checksum that is the two's complement of the sum of all preceding bytes in the record. È

{Original Message removed}

1997\06\04@123601 by Marc 'Nepomuk' Heuler

flavicon
face
Hi Rick (Rick Miller), in <.....199706031012.FAA29122KILLspamspam@spam@mail.execpc.com> on Jun 3 you
wrote:

> I wish I'd have kept all the stuff I got when I was in the same boat...
> looking for info for building free PIC development tools.  If I remember
> right, the format of the HEX file is detailed pretty extensively on
> Parallax's site (http://www.parallaxinc.com, I think) "somewhere".  Could you be
> sure and relay that info to the PICLIST when you've got it?

Funny.  Coincidentally, yesterday I did a several hour internet search for
the hex file format.

I am currently building a programmer as suggested in the "new programmer
idea" thread.  It connects to an RS232 port and parses an ASCII uploaded
hex file for programming (9600bps 8N1, serial pics only, battery powered,
small case).  I do this because my HP200LX Palmtop does not talk to any
other programmer I tried so far.

Here's what I found about the hex file format:

*****************************************************************

Below is a file representing the contents of a blank PIC16C54 as saved from
the PRO MATE programmer screen buffer in INHX8M format.


Below is a line of program data from the file:

:10004000FF0FFF0FFF0FFF0FFF0FFF0FFF0FFF0F40


This is how the line can be broken down:

column#:   01 0123 01 0123 0123 0123 0123 0123 0123 0123 0123 01
data type: BB AAAA TT HHHH HHHH HHHH HHHH HHHH HHHH HHHH HHHH CC
data:      10 0040 00 FF0F FF0F FF0F FF0F FF0F FF0F FF0F FF0F 40

Data Types explained:

The first two columns shown above (B1 and B2) are listed as data type BB.
BB is the number of DATA BYTES that will appear on the line (two digits in
hexadecimal).  Note that for the PIC16C5X, the data word is 12 bits,
represented as two bytes.  B0 is the low byte and B1 is the high byte of
the line count, so the bytes appear reversed.  In this example BB=10, 16
decimal.  This means there are 16 bytes on this line (or 8 12-bit program
words).

AAAA is the starting address (four digits in hexidecimal).  Recall that the
PIC16C5X is a 12 bit instruction word.  Two data bytes are required to
supply this data, with the upper nibble of the upper byte being 0 since it
does not exist in the part.  The address is incremented on the BYTE, NOT on
the PROGRAM WORD.  The address shown on the line is therefore double the
address location the data will be programmed into.  In this example AAAA =
0040, or decimal 64.  The data in this line will be programmed to the part
starting at the device address of 0020 hex, or 32 decimal (half the address
value shown on the line).

TT is record type designator.  It will always be 00, except at the end of
file record which is set to 01.

HHHH is the two byte data word to be programmed into the part.  Note that
they are ordered least significant byte first, then most sigificant byte.
Since in this example the part is blank, all of the locations are 0FFF hex.
However the data actually appears as FFF0.  In other words, columns H0 and
H1 make up the lower byte (FF, with H0 as Most Significant Byte) and
columns H2 and H3 make up the upper byte (0F, with H2 as MSB).

CC is the two-digit hexadecimal checksum that is the two's complement of
the sum of all the preceding bytes in the record including the byte count.
(10 + 00 + 40 + 00 + FF + 0F + FF + 0F + FF + 0F + FF + 0F + FF + 0F + FF +
0F + FF +0F + FF + 0F) = 08C0 hex.  Two's compliment (invert and add one)
is F740.  When truncated to one byte it is 40 hex, which is the number
shown in the example.

Below is the third to last line as shown in this file.  It contains the
information for the ID locations.  In the PIC16C5X there are four ID
locations, starting at 200 hex, and only the lower nibble of each location
is programmed.  When viewed in the current revision of PRO MATE the four
nibbles are shown together.  When blank they are displayed as FFFF hex on
the screen.  However when the part is programmed, the data actually goes to
four separate bytes locations 200 to 203 hex.  Each unprogrammed ID
location is therefore represented as 000F hex in this programming file.

:080400000F000F000F000F00B8

The line shown below is for the configuration word.  It is the second to
last line, as shown in this file.  (the last line is the end of record
line)

:021FFE00FF0FD3

There are two bytes, as stated by the 02.  They are programmed at 1FFE
divided by two, or FFF hex.  In this case the configuration word is blank,
so it is 0FFF hex.  Below is an example of the same line from a part with
the configuration word programmed to WDT enabled, Code protect on, LP mode.

:021FFE00F00FE2

Notice that this time the part will be programmed with FF0 in the
configuration word.  Only the lower four bits are used in the PIC16C5X to
program the configuration word, and in this case they are all programmed.

There may be subtle differences from this file to those for other parts,
since configuration word and ID locations may be handled differently.

1997\06\05@131052 by ame

flavicon
face
    > I wish I'd have kept all the stuff I got when I was in the same
    boat...
    > looking for info for building free PIC development tools.  If I
    remember
    > right, the format of the HEX file is detailed pretty extensively on
    > Parallax's site (http://www.parallaxinc.com, I think) "somewhere".  Could
    you be
    > sure and relay that info to the PICLIST when you've got it?

    Funny.  Coincidentally, yesterday I did a several hour internet search
    for the hex file format.

    --

    Funny.  I did a several second search and found that the Hex file
    formats are documented in the MPASM help file, appendix A.

    Strange that the documentation should be found in Microchip's stuff...

    Andy (the other one)

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...