codinghead / intel-hex-class

Class to decode, encode and manipulate Intel HEX files

Intel HEX Class Project

Introduction to the Intel HEX Class Module

The Intel HEX Class Module is designed to allow the programmer to easily work with Intel HEX files. Using standard C++ stream operators it is possible to decode a file into memory and then to examine the entire content of the file much more easily than if the original file was simply opened in a text editor.

Additionally, again using a C++ stream operator, it is possible to encode the current data in memory back into Intel HEX format again straight to a file.

Using this class it is also possible to:

• Generate Intel HEX files with your own content
• Fill blank areas of an Intel HEX file with a desired value or pattern
• Merge two or more files together
• Selectively merge parts of two or more files together
• Check an Intel HEX file for correctness and integrity (correct construction, checksums ok, etc.)

Key Software Capabilities

• Stream Intel HEX file content into class for decoding
• Stream data stored in memory out from class in Intel HEX format to a file
• 'Never give up' approach to decoding; warning and error messages can be examined upon completion; as much as humanely possible will have been decoded.
• Class contains no 'try' calls; will always return cleanly for programmer to make decision how to proceed.
• File sizes up to 4GB supported (system dependent).
• All records as per the official Intel "Hexadecimal Object File Format Specification, Revision A, January 6, 1988" supported

intel-hex-class's Issues

No ability to write arbitrary content

Even though the readme states that it is possible to insert your own content, the insertData method is actually not implemented. Took me some time to figure out that there is really no code for that yet.
I guess i'll make the rather old code from here work for me for now:
http://www.pjrc.com/tech/8051/ihex.c

Add unit tests

It would be nice to have some unit tests.

Wrong segment address (LSB instead of MSB) for output file

When writing HEX to output file, the segment address is output in LSB byte order while it must use MSB

Example 1 - First record at the beginning of the file :
Segment offset is 0x0800 and full data address is 0x08008000 (correct)
:020000040800F2
:10800000F0FC0020493D03083140030835400308D7

Written file contains
:020000040008F2
:10800000F0FC0020493D03083140030835400308D7
Segment offset is 0x0008 and full data address is 0x00088000 which is obviously wrong

Example 2 - Segment address record somewhere in the file
Segment offset is 0x0802 and full data address is 0x08020000 (correct)
:020000040802F0
:1000000002D1E4B2002C07D068714FF4FA6168792C

Written file contains
:020000040208F0
:1000000002D1E4B2002C07D068714FF4FA6168792C
Segment offset is 0x0208 and full data address is 0x02080000 (wrong)

Compare length of record with actual record length

Need to ensure that, when decoding records, we check that the data part of the record has the same length as the length of record as given in the record itself

Documentation file is not for Intel Hex

The file in the doc directory appears to be for a CBUFF class, not the Intel hex class.

Wrong block size when there is a jump in segment address

We have a hex file that has data record with same baseSegment address

The file has address jumps between sectors but has same baseSegment address

Current class file has implementation for getting the segment info gives the correct number of segment address using getSegmentinfo(). "2" in our case, x00010000 and x00030000. The class also gives the block size for each segment address which are 47892 and 65536.

The class file while calculating the block size is assuming the start of the address is always "x0000", takes the last address in the sector (which is "x0001BB14") as its block-size (which is 47892 in our case). This calculation would be wrong as the start address is not zero always (like in our x3000xxxx sector and between our x1000xxxx sectors where it-jumps/start-with-non-zero address). These jumps should be taken into account.

If we do consider the jumps and non-zero-start-address, actual block-size should be 40992 (including the address jumps) for the first segment and 1024 for the second segment.

Each sector calculation is done as below
sectorStartAddresses: x00010000 totalSectordataLength: x2ec
sectorStartAddresses: x00011000 dataLength: x238
sectorStartAddresses: x00012000 dataLength: x378
sectorStartAddresses: x00012380 dataLength: x8544
sectorStartAddresses: x0001a8c8 dataLength: xfdc
sectorStartAddresses: x0001b8a8 dataLength: x1fc
sectorStartAddresses: x0001baa8 dataLength: x64
sectorStartAddresses: x0001bb10 dataLength: x4

Hoping to collaborate and make this code work for both cases.

HEX file analysis crashes on Windows XP for non HEX file content

When opening a file that does not actually contain Intel HEX encoded data, the application code crashes.

This could occur when opening a '.hex' file in the wrong format.

Recommend reviewing decoding code and aborting the decode if the first line or first two lines do not start with the ':' start of record symbol.