Post by thread:Interpreting .HEX Files?

At 04:08 PM 7/9/98 -0700, you wrote: >I have been trying to figure out how to read .hex files created by the mpasm >compiler. Does anyone know how to interpret them or where I could find the >info? Hi Mike, If your MPASM is a windows version, I am sure you can find the info in the help, where ---------------------------------------- Appendix A. Hex File Formats Introduction Highlights Hex File Formats ---------------------------------------- Good Luck Jerry

Jerry Meng escreveu: > At 04:08 PM 7/9/98 -0700, you wrote: > >I have been trying to figure out how to read .hex files created by the mpasm > >compiler. Does anyone know how to interpret them or where I could find the > >info? if you want i've done a dos program to convert .hex files to plain binary format , to send to an eprom...

On Thu, 9 Jul 1998, Mike Hamilton wrote: > I have been trying to figure out how to read .hex files created by the mpasm > compiler. Does anyone know how to interpret them or where I could find the > info? Hex files for PICs on Intel are raw binary data. Since each word on a PIC takes more than one byte, they are packed in two bytes each, with some bits unused. To edit the file, use a hex editor (ex: Norton Diskedit will do that). To make sense of them, you need a simulator or a disassembler. The simulator can execute such a file directly, the disassembler can turn it into source code (assembly) minus the symbols. Peter

On Thu, 9 Jul 1998, Peter L. Peres wrote: > >Hex files for PICs on Intel are raw binary data. Since each word on a PIC >takes more than one byte, they are packed in two bytes each, with some >bits unused. > >To edit the file, use a hex editor (ex: Norton Diskedit will do that). To >make sense of them, you need a simulator or a disassembler. The simulator >can execute such a file directly, the disassembler can turn it into source >code (assembly) minus the symbols. > >Peter .HEX files are not in raw binary form, they are ASCII format, each line being a data record,terminated in a CR/LF, with the following format: :BBAAAATTHHHHHHHH......HHHHCC Where: BB Two digit hex byte count representing the number of data words that will appear on the line. AAAA Four digit hex address representing the starting address for the data record. TT Two digit record type that will always be '00' except for the end-of-file record which is set to '01' HH Two digit hex data word CC Two digit hex checksum that is the two's complement of the sum of all preceding bytes in the record including the prefix bytes. The format was originally for 8 bit data (INTEL Intellec 8/MDS Format) but has been extendeed for 12,14,16 bit data words by having two bytes for each address location, in low byte,high byte order (little endian). So if you open this with a hex editor you will see something like: 3A 31 30 30 30 30 30 30 30 47 42 30 34 ............ :10000000FA04....... Which, while not being impossible to work with, is probably not the best way to do it, just use Notepad, Wordpad, DOS Edit, Edlin or better still PFE or WINedit, you can even use Word, but I'm not a masochist! TTFN Paul

On Fri, 10 Jul 1998, Paul BRITTON wrote: > .HEX files are not in raw binary form, they are ASCII format, each line > being a data record,terminated in a CR/LF, with the following format: My impression was, that .HEX files are raw images (.HEX == .BIN). You may be right, though. Anyway, most reasonable tools call this format 'object format', and give it an extension of .OBJ or .S19... > The format was originally for 8 bit data (INTEL Intellec 8/MDS Format) but > has been extendeed for 12,14,16 bit data words by having two bytes for > each address location, in low byte,high byte order (little endian). imho, wrong. The default .OBJ file output by PICALC under DOS is INHX16 which is big endian. The INHX8M is the little endian version (and it confused the hell out of the 1st parser I wrote for .OBJ files - the only way to automatically tell the type is rewriting, as the checksum applies correctly for each line if you swap the bytes around). > Which, while not being impossible to work with, is probably not the best > way to do it, just use Notepad, Wordpad, DOS Edit, Edlin or better still > PFE or WINedit, you can even use Word, but I'm not a masochist! How can these edit 8-bit codes ? I think that all Windows programs will pop up something (a fuse ?) sooner or later as you try entering secret codes <G>. Peter

> Van: Mike Hamilton <spam_OUTmikeh9TakeThisOuTEARTHLINK.NET> > Aan: .....PICLISTKILLspam@spam@MITVMA.MIT.EDU > Onderwerp: Interpreting .HEX Files? > Datum: vrijdag 10 juli 1998 1:08 > > I have been trying to figure out how to read .hex files created by the mpasm > compiler. Does anyone know how to interpret them or where I could find the > info? Yes, someone does :-) It's (if I'm not mistaken) the Intel HEX-format See below: : 10 0150 00 8F0D900D901010158E010C1703100800 D4 | | | | | | | | | | | \- Checksum | | | | \- data-bytes | | | \- Record -type (00 - Data, 01 - end-of-file) | | \- Storage-adress (divide by two for 14/16 bit cores) | \- Number of DATA bytes \- Start char Checksum : Subtract ALL hex-bytes from 0x00 (including the Checksum-byte) the result should be 0x00 (Or add all bytes EXCUSIVE the checksum. It should than _match_ the checksum) CTRL-chars in front/back are ignored (CR, LF,TAB,SPACE). Want/need to know more ? Let me know. Greetz, Rudy Wieser

Hi Peter and others, Actually, the standard Intel .HEX format is NOT raw binary data. It consists of ASCII text numerals and letters which represent hex numbers, i.e. A0B355 would be the hex number A0B355, just as it looks. Therefore, you can view the file in any text editor, you should not need a hex editor. The .HEX files produced by MPASM, I think, also follow this standard, but I cannot be 100% sure since I do not usually use MPASM. I am at work right now, but at home I have a file which describes the .HEX format. I got it off the web. IF you do a search, you will probably come up with it. Good Luck, Sean On Fri, 10 Jul 1998, Peter L. Peres wrote: {Quote hidden}> Hex files for PICs on Intel are raw binary data. Since each word on a PIC > takes more than one byte, they are packed in two bytes each, with some > bits unused. > > To edit the file, use a hex editor (ex: Norton Diskedit will do that). To > make sense of them, you need a simulator or a disassembler. The simulator > can execute such a file directly, the disassembler can turn it into source > code (assembly) minus the symbols. > > Peter >

Peter L. Peres wrote: > My impression was, that .HEX files are raw images (.HEX == .BIN). No, that's exactly the point; .HEX =/= .BIN Very specific here. > Anyway, most reasonable tools call this format 'object format', and > give it an extension of .OBJ or .S19... I'm not sure about the .OBJ bit. While the .HEX format has much embedded information; addresses for isolated segments, "type" fields and "run" addresses, I understand .OBJ format has much more, linking data to be specific. And this format can *not* be .S19 for the very simple reason - it *isn't* S1/S9 format! > The default .OBJ file output by PICALC under DOS is INHX16 which is > big endian. The INHX8M is the little endian version (and it > confused the hell out of the 1st parser I wrote for .OBJ files - the > only way to automatically tell the type is rewriting, as the checksum > applies correctly for each line if you swap the bytes around). Well, sounds like you *have* looked into this bit! > How can these edit 8-bit codes? I think that all Windows programs > will pop up something (a fuse ?) sooner or later as you try entering > secret codes <G>. But .HEX files do not *contain* 8-bit codes. They are totally 7-bit *text* in which control characters have their ASCII meaning. Indeed, any ASCII editor will edit them just fine. You can edit the hex to alter the 8-bit values it *represents* as long as you fix the checksum accordingly. -- Cheers, Paul B.

Only format correction: The spaces in the muster line don't exists. They are inserted here only for the sake of readibility. All numbers are to be interpreted in hex. If one wants to edit that line, the checksum and possibly the length field must be maintained. The change in the length can affect the storage address field also. So I advice to follow the following schema: 1. Read in and interpret all data in a contiguous storage area. 2. Edit this storage area as you want. 3. Write out it in the appropriate format. Imre On Mon, 13 Jul 1998, Caisson wrote: {Quote hidden}> > Van: Mike Hamilton <mikeh9KILLspamEARTHLINK.NET> > > Aan: .....PICLISTKILLspam.....MITVMA.MIT.EDU > > Onderwerp: Interpreting .HEX Files? > > Datum: vrijdag 10 juli 1998 1:08 > > > > I have been trying to figure out how to read .hex files created by the > mpasm > > compiler. Does anyone know how to interpret them or where I could find > the > > info? > > Yes, someone does :-) > > It's (if I'm not mistaken) the Intel HEX-format > > See below: > > : 10 0150 00 8F0D900D901010158E010C1703100800 D4 > | | | | | | > | | | | | | > | | | | | | > | | | | | \- Checksum > | | | | \- data-bytes > | | | \- Record -type (00 - Data, 01 - end-of-file) > | | \- Storage-adress (divide by two for 14/16 bit cores) > | \- Number of DATA bytes > \- Start char > > Checksum : Subtract ALL hex-bytes from 0x00 (including the Checksum-byte) > the result should be 0x00 (Or add all bytes EXCUSIVE the checksum. It > should than _match_ the checksum) > > CTRL-chars in front/back are ignored (CR, LF,TAB,SPACE). > > Want/need to know more ? Let me know. > > Greetz, > Rudy Wieser > >