From 2fbdf974338bde8576efdae40a819a76b2391033 Mon Sep 17 00:00:00 2001 From: "Juan J. Martinez" Date: Sun, 5 Nov 2023 11:22:55 +0000 Subject: Initial import of the open source release --- tools/hex2bin-2.0/doc/CRC list.txt | 542 ++++++++++++++++++++++++++++++++ tools/hex2bin-2.0/doc/ChangeLog_hex2bin | 57 ++++ tools/hex2bin-2.0/doc/ChangeLog_mot2bin | 49 +++ tools/hex2bin-2.0/doc/README | 225 +++++++++++++ tools/hex2bin-2.0/doc/S-record.txt | 361 +++++++++++++++++++++ tools/hex2bin-2.0/doc/formats.txt | 72 +++++ tools/hex2bin-2.0/doc/intelhex.spc | 409 ++++++++++++++++++++++++ tools/hex2bin-2.0/doc/srec.txt | 447 ++++++++++++++++++++++++++ 8 files changed, 2162 insertions(+) create mode 100644 tools/hex2bin-2.0/doc/CRC list.txt create mode 100644 tools/hex2bin-2.0/doc/ChangeLog_hex2bin create mode 100644 tools/hex2bin-2.0/doc/ChangeLog_mot2bin create mode 100644 tools/hex2bin-2.0/doc/README create mode 100644 tools/hex2bin-2.0/doc/S-record.txt create mode 100644 tools/hex2bin-2.0/doc/formats.txt create mode 100644 tools/hex2bin-2.0/doc/intelhex.spc create mode 100644 tools/hex2bin-2.0/doc/srec.txt (limited to 'tools/hex2bin-2.0/doc') diff --git a/tools/hex2bin-2.0/doc/CRC list.txt b/tools/hex2bin-2.0/doc/CRC list.txt new file mode 100644 index 0000000..8549799 --- /dev/null +++ b/tools/hex2bin-2.0/doc/CRC list.txt @@ -0,0 +1,542 @@ +http://regregex.bbcmicro.net/crc-catalogue.htm + +CRC-8 +07 + + Name : "CRC-8" + Width : 8 + Poly : 07 + Init : 00 + RefIn : False + RefOut : False + XorOut : 00 + Check : F4 + + + Name : "CRC-8/ITU" + Width : 8 + Poly : 07 + Init : 00 + RefIn : False + RefOut : False + XorOut : 55 + Check : A1 + + + Name : "CRC-8/ROHC" + Width : 8 + Poly : 07 + Init : FF + RefIn : True + RefOut : True + XorOut : 0 + Check : D0 + +39 + + Name : "CRC-8/DARC" + Width : 8 + Poly : 39 + Init : 00 + RefIn : True + RefOut : True + XorOut : 00 + Check : 15 + +1D + + Name : "CRC-8/I-CODE" + Width : 8 + Poly : 1D + Init : FD + RefIn : False + RefOut : False + XorOut : 00 + Check : 7E + + + Name : "CRC-8/J1850" (new entry) + Width : 8 + Poly : 1D + Init : FF + RefIn : False + RefOut : False + XorOut : FF + Check : 4B + +31 + + Name : "CRC-8/MAXIM" + Alias : "DOW-CRC" + Width : 8 + Poly : 31 + Init : 00 + RefIn : True + RefOut : True + XorOut : 00 + Check : A1 + +9B + + Name : "CRC-8/WCDMA" + Width : 8 + Poly : 9B + Init : 00 + RefIn : True + RefOut : True + XorOut : 00 + Check : 25 + +8D + + Name : "CRC-8/CCITT" (new entry) 1-Wire? + Width : 8 + Poly : 8D + Init : 00? + RefIn : False? + RefOut : False? + XorOut : 00? + Check : D2 + +D5 + + Name : "CRC-8" (new entry) + Width : 8 + Poly : D5 + Init : 00? + RefIn : False? + RefOut : False? + XorOut : 00? + Check : BC + +CRC-16 +8005 + + Name : "ARC" + Alias : "CRC-16" + Alias : "CRC-IBM" + Alias : "CRC-16/ARC" + Alias : "CRC-16/LHA" + Width : 16 + Poly : 8005 + Init : 0000 + RefIn : True + RefOut : True + XorOut : 0000 + Check : BB3D + + + Name : "CRC-16/BUYPASS" + Alias : "CRC-16/VERIFONE" + Width : 16 + Poly : 8005 + Init : 0000 + RefIn : False + RefOut : False + XorOut : 0000 + Check : FEE8 + + + Name : "CRC-16/DDS-110" + Width : 16 + Poly : 8005 + Init : 800D + RefIn : False + RefOut : False + XorOut : 0000 + Check : 9ECF + XCheck : CFE9 + + + Name : "CRC-16/MAXIM" + Width : 16 + Poly : 8005 + Init : 0000 + RefIn : True + RefOut : True + XorOut : FFFF + Check : 44C2 + + + Name : "CRC-16/USB" + Width : 16 + Poly : 8005 + Init : FFFF + RefIn : True + RefOut : True + XorOut : FFFF + Check : B4C8 + + + Name : "MODBUS" + Width : 16 + Poly : 8005 + Init : FFFF + RefIn : True + RefOut : True + XorOut : 0000 + Check : 4B37 + +1021 + + Name : "CRC-16/AUG-CCITT" + Alias : "CRC-16/SPI-FUJITSU" + Width : 16 + Poly : 1021 + Init : 1D0F + RefIn : False + RefOut : False + XorOut : 0000 + Check : E5CC + + + Name : "CRC-16/CCITT-FALSE" + Width : 16 + Poly : 1021 + Init : FFFF + RefIn : False + RefOut : False + XorOut : 0000 + Check : 29B1 + + + Name : "CRC-16/GENIBUS" + Alias : "CRC-16/I-CODE" + Alias : "CRC-16/DARC" + Width : 16 + Poly : 1021 + Init : FFFF + RefIn : False + RefOut : False + XorOut : FFFF + Check : D64E + + + Name : "XMODEM" + Alias : "ZMODEM" + Alias : "CRC-16/ACORN" + Width : 16 + Poly : 1021 + Init : 0000 + RefIn : False + RefOut : False + XorOut : 0000 + Check : 31C3 + + + Name : "CRC-16/MCRF4XX" + Width : 16 + Poly : 1021 + Init : FFFF + RefIn : True + RefOut : True + XorOut : 0000 + Check : 6F91 + + + Name : "CRC-16/RIELLO" + Width : 16 + Poly : 1021 + Init : B2AA + RefIn : True + RefOut : True + XorOut : 0000 + Check : 63D0 + + + Name : "KERMIT" + Alias : "CRC-16/CCITT" + Alias : "CRC-16/CCITT-TRUE" + Alias : "CRC-CCITT" + Width : 16 + Poly : 1021 + Init : 0000 + RefIn : True + RefOut : True + XorOut : 0000 + Check : 2189 + XCheck : 8921 + + + Name : "X-25" + Alias : "CRC-16/IBM-SDLC" + Alias : "CRC-16/ISO-HDLC" + Width : 16 + Poly : 1021 + Init : FFFF + RefIn : True + RefOut : True + XorOut : FFFF + Check : 906E + XCheck : 6E90 + +0589 + + Name : "CRC-16/DECT-R" + Alias : "R-CRC-16" + Width : 16 + Poly : 0589 + Init : 0000 + RefIn : False + RefOut : False + XorOut : 0001 + Check : 007E + + + Name : "CRC-16/DECT-X" + Alias : "X-CRC-16" + Width : 16 + Poly : 0589 + Init : 0000 + RefIn : False + RefOut : False + XorOut : 0000 + Check : 007F + +3D65 + + Name : "CRC-16/DNP" + Width : 16 + Poly : 3D65 + Init : 0000 + RefIn : True + RefOut : True + XorOut : FFFF + Check : EA82 + XCheck : 82EA + + + Name : "CRC-16/EN-13757" + Width : 16 + Poly : 3D65 + Init : 0000 + RefIn : False + RefOut : False + XorOut : FFFF + Check : C2B7 + +8BB7 + + Name : "CRC-16/T10-DIF" + Width : 16 + Poly : 8BB7 + Init : 0000 + RefIn : False + RefOut : False + XorOut : 0000 + Check : D0DB + +A097 + + Name : "CRC-16/TELEDISK" + Width : 16 + Poly : A097 + Init : 0000 + RefIn : False + RefOut : False + XorOut : 0000 + Check : 0FB3 + +CRC-24 +864CFB + + Name : "CRC-24" + Alias : "CRC-24/OPENPGP" + Width : 24 + Poly : 864CFB + Init : B704CE + RefIn : False + RefOut : False + XorOut : 000000 + Check : 21CF02 + +5D6DCB + + Name : "CRC-24/FLEXRAY-A" + Width : 24 + Poly : 5D6DCB + Init : FEDCBA + RefIn : False + RefOut : False + XorOut : 000000 + Check : 7979BD + + + Name : "CRC-24/FLEXRAY-B" + Width : 24 + Poly : 5D6DCB + Init : ABCDEF + RefIn : False + RefOut : False + XorOut : 000000 + Check : 1F23B8 + +CRC-32 +04C11DB7 + + Name : "CRC-32" + Alias : "CRC-32/ADCCP" + Alias : "PKZIP" + Width : 32 + Poly : 04C11DB7 + Init : FFFFFFFF + RefIn : True + RefOut : True + XorOut : FFFFFFFF + Check : CBF43926 + + + Name : "CRC-32/BZIP2" + Alias : "B-CRC-32" + Width : 32 + Poly : 04C11DB7 + Init : FFFFFFFF + RefIn : False + RefOut : False + XorOut : FFFFFFFF + Check : FC891918 + + + Name : "CRC-32/MPEG-2" + Width : 32 + Poly : 04C11DB7 + Init : FFFFFFFF + RefIn : False + RefOut : False + XorOut : 00000000 + Check : 0376E6E7 + + + Name : "CRC-32/POSIX" + Alias : "CKSUM" + Width : 32 + Poly : 04C11DB7 + Init : 00000000 + RefIn : False + RefOut : False + XorOut : FFFFFFFF + Check : 765E7680 + LCheck : 377A6011 + + + Name : "JAMCRC" + Width : 32 + Poly : 04C11DB7 + Init : FFFFFFFF + RefIn : True + RefOut : True + XorOut : 00000000 + Check : 340BC6D9 + +1EDC6F41 + + Name : "CRC-32C" + Alias : "CRC-32/ISCSI" + Alias : "CRC-32/CASTAGNOLI" + Width : 32 + Poly : 1EDC6F41 + Init : FFFFFFFF + RefIn : True + RefOut : True + XorOut : FFFFFFFF + Check : E3069283 + +A833982B + + Name : "CRC-32D" + Width : 32 + Poly : A833982B + Init : FFFFFFFF + RefIn : True + RefOut : True + XorOut : FFFFFFFF + Check : 87315576 + +741B8CD7 + (new entry) + Name : "CRC-32K" + Alias : "CRC-32/KOOPMAN" + Width : 32 + Poly : 741B8CD7 + Init : 00000000? + RefIn : False? + RefOut : False? + XorOut : 00000000? + Check : 085A3197 ? + +814141AB + + Name : "CRC-32Q" + Width : 32 + Poly : 814141AB + Init : 00000000 + RefIn : False + RefOut : False + XorOut : 00000000 + Check : 3010BF7F + +000000AF + + Name : "XFER" + Width : 32 + Poly : 000000AF + Init : 00000000 + RefIn : False + RefOut : False + XorOut : 00000000 + Check : BD0BE338 + +CRC-40 + + Name : "CRC-40/GSM" + Width : 40 + Poly : 0004820009 + Init : 0000000000 + RefIn : False + RefOut : False + XorOut : 0000000000 + Check : 2BE9B039B9 + +CRC-64 +42F0E1EBA9EA3693 + + Name : "CRC-64" + Width : 64 + Poly : 42F0E1EBA9EA3693 + Init : 0000000000000000 + RefIn : False + RefOut : False + XorOut : 0000000000000000 + Check : 6C40DF5F0B497347 + + + Name : "CRC-64/WE" + Width : 64 + Poly : 42F0E1EBA9EA3693 + Init : FFFFFFFFFFFFFFFF + RefIn : False + RefOut : False + XorOut : FFFFFFFFFFFFFFFF + Check : 62EC59E3F1A4F00A + +000000000000001B + + Name : "CRC-64/1B" (New entry) + Width : 64 + Poly : 000000000000001B + Init : 0000000000000000 + RefIn : True + RefOut : True + XorOut : 0000000000000000 + Check : 46A5A9388A5BEFFE + +AD93D23594C935A9 + + Name : "CRC-64/Jones" (New entry) + Width : 64 + Poly : AD93D23594C935A9 + Init : FFFFFFFFFFFFFFFF + RefIn : True + RefOut : True + XorOut : 0000000000000000 + Check : CAA717168609F281 diff --git a/tools/hex2bin-2.0/doc/ChangeLog_hex2bin b/tools/hex2bin-2.0/doc/ChangeLog_hex2bin new file mode 100644 index 0000000..3339250 --- /dev/null +++ b/tools/hex2bin-2.0/doc/ChangeLog_hex2bin @@ -0,0 +1,57 @@ +(UTF8 encoding) + +- hex2bin 1.0.12 - 20141122 Simone Fratini + small feature added + 20141121 Slucx + added line for removing extra CR when entering file name at run time. + 20141008 JP + removed junk code + +- hex2bin 1.0.11 - 20141005 Jacques Pelletier + added option to support byte-swapped hex used by Microchip's MPLAB IDE + corrected bug caused by extra LF at end or within file + +- hex2bin 1.0.10 - 20120509 Yoshimasa Nakane + modified error checking (also for output file, JP) + modified option parser (JP) + +- hex2bin 1.0.9 - 20120125 - Danny Schneider + Added code for filling a binary file to a given Max_Length relative to + Starting Address if Max-Address is larger than Highest-Address + +- hex2bin 1.0.8 - 20100402 - Jacques Pelletier + Fixed a bug with physical address calculation with extended linear address records + ADDRESS_MASK is now calculated from MEMORY_SIZE + +- hex2bin 1.0.7 - 20091212 - Jacques Pelletier + Fixed the crash on 0 byte length data records + +- hex2bin 1.0.6 - 20080103 - Jacques Pelletier + Fixed a bug when generating binary files near the end of the buffer + +- hex2bin 1.0.5 - 20071005 - Paweł Grabski - + Improved parsing of options. + +- hex2bin 1.0.4 - 20050126 - Jacques Pelletier - + Corrected the conversion LF -> CR+LF bug + applied patch for correcting the incorrect handling of + extended segment address record + added the Rockwell checksum extensions, and modified them a bit to allow + other types later. + +- hex2bin 1.0.3 - 20040617 - Alf Lacis - + Added pad byte (may not always want FF). + Added 'break;' to remove GNU compiler warning about label at + end of compound statement + Added PROGRAM & VERSION strings. + +- hex2bin 1.0.2 - + Corrected Bug in checksum verification + +- hex2bin 1.0.1 - + Added checking for memory indexing out of bound. + Added segmented and linear extended addressing in hex2bin. + Corrected an error: & were interverted with && (and bitwise, logical and). + +- hex2bin 1.0.0 - + Initial release diff --git a/tools/hex2bin-2.0/doc/ChangeLog_mot2bin b/tools/hex2bin-2.0/doc/ChangeLog_mot2bin new file mode 100644 index 0000000..4e3c7b3 --- /dev/null +++ b/tools/hex2bin-2.0/doc/ChangeLog_mot2bin @@ -0,0 +1,49 @@ +(UTF8 encoding tab = 4) +- mot2bin 1.0.12 - 20141122 Simone Fratini + small feature added + 20141121 Slucx + added line for removing extra CR when entering file name at run time. + +- mot2bin 1.0.11 - 20141005 Jacques Pelletier + added option to support byte-swapped hex used by Microchip's MPLAB IDE + corrected bug caused by extra LF at end or within file + +- mot2bin 1.0.10 - 20120509 Yoshimasa Nakane + modified error checking (also for output file, JP) + +- mot2bin 1.0.9 - 20120125 - Danny Schneider + Added code for filling a binary file to a given Max_Length relative to + Starting Address if Max-Address is larger than Highest-Address + (JP) corrected a bug in the checksum checking + (JP) added code for record types 0,5,7,8,9 + +- mot2bin 1.0.8 - 20100402 - Jacques Pelletier + ADDRESS_MASK is now calculated from MEMORY_SIZE + +- mot2bin 1.0.7 - 20091212 - Jacques Pelletier + Fixed the crash on 0 byte length data records + +- mot2bin 1.0.6 - 20080103 - Jacques Pelletier + Corrected a bug when generating a binary file near the end of the buffer. + +- mot2bin 1.0.5 - 20071005 - Paweł Grabski - + Improved parsing of options (same code as hex2bin). + +- mot2bin 1.0.4 - 20050128 - Jacques Pelletier - + Modified the checksum code to be able to generate other checksum types + later (ex. CRC). + +- mot2bin 1.0.3 - 20041026 - Scott A. Mintz - + Modified the MOT2BIN file to compute a checksum over a range using + 8bit, 16bit little endian, or 16bit big endian and optionally forcing + the checksum to a specific value by modifying a memory location. + +- mot2bin 1.0.2 - 20040617 - Alf Lacis - + Added pad byte (may not always want FF). + Added initialisation to Checksum to remove GNU + compiler warning about possible uninitialised usage + Added 2x'break;' to remove GNU compiler warning about label at + end of compound statement + Added PROGRAM & VERSION strings. + +- no previous ChangeLog - diff --git a/tools/hex2bin-2.0/doc/README b/tools/hex2bin-2.0/doc/README new file mode 100644 index 0000000..78ee7e7 --- /dev/null +++ b/tools/hex2bin-2.0/doc/README @@ -0,0 +1,225 @@ +Yet Another Hex to bin converter + +It can handle the extended Intel hex format in segmented and linear address +modes. Records need not be sorted and there can be gaps between records. + +Some hex files are produced by compilers. They generate objects files for each +module in a project, and when the linker generates the final hex file, the +object files are stored within the hex files, but modules can appear not +necessary in order of address. + +How does it work? + +Hex2bin/mot2bin allocates a 4 MBytes buffer and just place the converted bytes +in its buffer. At the end, the buffer is written to disk. Using a buffer elimi- +nates the need to sort records. If the option l is used (3), the buffer will be +allocated with the maximum size specified if over 4Mbytes. + +Before reading the hex file, the buffer is filled with a default value. These +padding bytes are all FF by default so an EPROM programmer can skip these bytes +when programming. The padding value can be changed with the -p option. + +1. Compiling on Linux or other unix platforms + + make + + then + + make install + + This will install the program to /usr/local/bin. + +1a. Compiling for Windows on Msys, Cygwin or DOS prompt + + The programs can be compiled as follows: + gcc -O2 -Wall -o hex2bin.exe hex2bin.c common.c libcrc.c binary.c + gcc -O2 -Wall -o mot2bin.exe mot2bin.c common.c libcrc.c binary.c + +2. Using hex2bin + + hex2bin example.hex + + hex2bin will generate a binary file example.bin starting at the + lowest address in the hex file. + +3. Binary file starting address and length + + If the lowest address isn't 0000, + ex: 0100: (the first record begins with :nn010000xxx ) + + there will be problems when using the binary file to program a EPROM + since the first byte supposed to be at 0100 is stored in the binary file + at 0000. + + you can specify a starting address for the binary file on the command line: + + hex2bin -s 0000 start_at_0100.hex + + This start address is not the same thing as the start address record in + the hex file. The start address record is used to specify the starting + address for execution of the binary code. + + The bytes will be stored in the binary file with a padding from 0000 + to the lowest address minus 1 (00FF in this case). + + Similarly, the binary file can be padded up to Length -1 with FF or another byte. + + Here, the space between the last byte and 07FF will be filled with FF. + hex2bin -l 0800 ends_before_07FF.hex + + EPROM, EEPROM and Flash memories contain all FF when erased. + + This program does minimal error checking since many hex files are + generated by known good assemblers. + + When the source file name is + for-example.test.hex + the binary created will have the name + for-example.bin + the ".test" part will be dropped. + + Hex2bin/mot2bin assume the source file doesn't contain overlapping records, + if so, overlaps will be reported. + +4. Checksum of source file + + By default, it ignores record checksum errors, so that someone can change + by hand some bytes allowing quick and dirty changes. + If you want checksum error reporting, specify the option -c. + + hex2bin -c example.hex + + If there is a record checksum error somewhere, the program will continue the + conversion anyway. + + The example file example.hex contains some records with checksum errors. + +5. Check value inserted inside binary file + + A check value can be inserted in the resulting binary file. + + hex2bin -k [0-4] -r [start] [end] -f [address] -C [Poly] [Init] [RefIn] [RefOut] [XorOut] + + -k Select the check method: + 0: Checksum 8-bit + 1: Checksum 16-bit + 2: CRC8 + 3: CRC16 + 4: CRC32 + + -r Range to compute checksum over (default is min and max addresses) + + -f Address of the result to write + + -C Parameters for CRC + Parameters for common CRCs are listed in doc/CRC list.txt. They appear in + the same order. Feed them as is and use t for TRUE, f for FALSE. + + See also the test/Makefile for these common CRCs; since they're tested, + you'll have the command line figured out. + + -E Endian for storing the check result or forcing it + 0: little + 1: big + + Change from previous versions of hex2bin/mot2bin: + Replace former options to this version + -k 1 -> -k 1 -E 0 + -k 2 -> -k 1 -E 1 + +6. Value inserted directly inside binary file + Instead of calculating a value, it can be inserted directly into the file at a specified address. + + hex2bin -k [0|1|2] -F [address] [value] + + -k Select the value format: + + 0 = 8-bit + 1 = 16-bit + 2 = 32-bit + + -F Address and value of checksum to force + + -E Endian for storing the check result or forcing it + 0: little + 1: big + +7. Motorola S files + + mot2bin example.s19 + + Options for mot2bin are the same as hex2bin. Executing the program + without argument will display available options. Some are specific to + Motorola files. + + This program will handle S19 files generated for Motorola micropro- + cessors. Since I use this program for an EPROM programmer, I will + rarely need to have more than 4M, I limited the source program for + 24 bits or 16 bits address records. + + 32 bits records are now supported, but obviously I can't allocate all + the memory for the binary target. What I did is simply assume that the + binary file will occupy less than 4M. For binary files greater than 4M, + see length option (section 3). + +8. Support for byte-swapped hex/S19 files + + -w Wordwise swap: for each pair of bytes, exchange the low and high part. + If a checksum needs to be generated to insert in the binary file, select + one of the 16-bit checksums. + + hex2bin -w test-byte-swap.hex + +9. Goodies + + Description of the file formats is included. + Added examples files for extended addressing. + + Check for overlapping records. The check is rather basic: supposing + that the buffer is filled with pad bytes, when a record overlaps a + previous one, value in the buffer will be different from the pad bytes. + This will not detect the case when the previous value equals the pad byte, + but it's more likely that more than one byte will be overlapped. + + +10. Error messages + + "Can't allocate memory." + + Can't do anything in this case, so the program simply exits. + + "Error occurred while reading from file" + + Problem with fgets. + + "Input/Output file %s cannot be opened. Enter new filename: " + + The user may not have permissions to open the file. + + "0 byte length data record ignored" + + This means that an empty data record was read. Since it's empty, it's simply + ignored and should have no impact on the binary file. + + "Data record skipped at ..." + + This means that the records are falling outside the memory buffer. + + "Overlapped record detected" + + A record is overwritten by a subsequent record. If you're using SDCC, check + if more than one area is specified with a starting address. Checking the map + file generated by the linker can help. + + "Some error occurred when parsing options." + + + +11. History + + See ChangeLog + +12. Other hex tool + + There is a program that supports more formats and has more features. + See SRecord at http://srecord.sourceforge.net/ diff --git a/tools/hex2bin-2.0/doc/S-record.txt b/tools/hex2bin-2.0/doc/S-record.txt new file mode 100644 index 0000000..ba4abc1 --- /dev/null +++ b/tools/hex2bin-2.0/doc/S-record.txt @@ -0,0 +1,361 @@ +S-Record Format + + A file in Motorola S-record format is an ASCII file. There are three different + formats: + + S19 for 16-bit address + S2 for 24-bit address + S3 for 32-bit address + + + The files consist of optional symbol table information, data specifications + for loading memory, and a terminator record. + + [ $$ {module_record} + symbol records + $$ [ module_record ] + symbol_records + $$] + header_record + data_records + record_count_record + terminator_record + + +Module Record (Optional) + + Each object file contains one record for each module that is a component of it. This + record contains the name of the module. There is one module record for each relocatable + object created by the assembler. The name of the relocatable object module + contained in the record comes from the IDNT directive. For absolute objects created + by the linker, there is one module record for each relocatable object file linked, + plus an additional record whose name comes from the NAME command for the + linker. + + Example: + + $$ MODNAME + + +Symbol Record (Optional) + + As many symbol records as needed can be contained in the object module. Up to 4 + symbols per line can be used, but it is not mandatory that each line contain 4 + symbols. A module can contain only symbol records. + + Example: + + APPLE $00000 LABEL1 $ODOC3 + MEM $OFFFF ZEEK $01947 + + The module name associated with the symbols can be specified in the + module_record preceding the symbol records. + + Example: + + $$MAIN + + Symbols are assumed to be in the module named in the preceding module_record + until another module is specified with another module_record. Symbols defined by + the linker's PUBLIC command appear following the first module record, which + indicates the name of the output object module specified by the linker's NAME + command. + + +***************************************************************************************** + +Header Record (SO) + + Each object module has exactly one header record with the following format: + + S00600004844521B + + Description: + + S0 Identifies the record as a header record + 06 The number of bytes following this one + 0000 The address field, which is ignored + 484452 The string HDR in ASCII + 1B The checksum + + + +***************************************************************************************** + +Data Record (S1) + + A data record specifies data bytes that are to be loaded into memory. Figure 1 + shows the format for such a record. The columns shown in the figure represent half + of a byte (4 bits). + + --------------------------------------------- + | 1 2 3 4 5 6 7 8 9 ... 40 41 42 | + | | + | S ID byte load data...data checksum | + | count address 1 n | + --------------------------------------------- + Figure 1: Data Record Formatter 16-Bit Load Address + + + Column Description + + 1 Contains the ASCII character S, which indicates the start of + a record in Motorola S-record format. + + 2 Contains the ASCII character identifying the record type. + For data records, this character is 1. + + 3 to 4 Contain the count of the number of bytes following this one + within the record. The count includes the checksum and the + load address bytes but not the byte count itself. + + 5 to 8 Contain the load address. The first data byte is to be loaded + into this address and subsequent bytes into the next sequential + address. Columns 5 and 6 contain the high-order address + byte, and columns 7 and 8 contain the low-order address byte. + + 9 to 40 Contain the specifications for up to 16 bytes of data. + + 41 to 42 Contain a checksum for the record. To calculate this, take the + sum of the values of all bytes from the byte count up to the + last data byte, inclusive, modulo 256. Subtract this result + from 255. + + +***************************************************************************************** + +Data Record (S2) + + + A data record specifies data bytes that are to be loaded into memory. Figure 2 + shows the format for such a record. The columns shown in the figure represent half + of a byte (4 bits). + + + ---------------------------------------------------- + | 1 2 3 4 5 6 7 8 9 10 11 ... 42 43 44 | + | | + | S ID byte load data...data checksum | + | count address 1 n | + ---------------------------------------------------- + Figure 2: Data Record Format for 24-Bit Load Address + + Column Description + + 1 Contains the ASCII character S, which indicates the start of + a record in Motorola S-record format. + + 2 Contains the ASCII character identifying the record type. + For data records, this character is 2. + + 3 to 4 Contain the count of the number of bytes following this one + within the record. The count includes the checksum and the + load address bytes but not the byte count itself. + + 5 to 10 Contain the load address. The first data byte is to be loaded + into this address and subsequent bytes into the next sequential + address. Columns 5 and 6 contain the high-order address + byte, and columns 9 and 10 contain the low-order address byte. + + 11 to 42 Contain the specifications for up to 16 bytes of data. + + 43 to 44 Contain a checksum for the record. To calculate this, take the + sum of the values of all bytes from the byte count up to the + last data byte, inclusive, modulo 256. Subtract this result + from 255. + + +***************************************************************************************** + +Data Record (S3) + + + A data record specifies data bytes that are to be loaded into memory. Figure 3 + shows the format for such a record. The columns shown in the figure represent half + of a byte (4 bits). + + ---------------------------------------------------------- + | 1 2 3 4 5 6 7 8 9 10 11 12 13 ... 44 45 46 | + | | + | S ID byte load data...data checksum | + | count address 1 n | + ---------------------------------------------------------- + Figure 3: Data Record Format for 32-Bit Load Address + + Column Description + + 1 Contains the ASCII character S, which indicates the start of + a record in Motorola S-record format. + + 2 Contains the ASCII character identifying the record type. + For data records, this digit is 3 for 32-bit addresses. + + 3 to 4 Contain the count of the number of bytes following this one + within the record. The count includes the checksum and the + load address bytes but not the byte count itself. + + 5 to 12 Contain the load address. The first data byte is to be loaded + into this address and subsequent bytes into the next sequential + address. Columns 5 and 6 contain the high-order address + byte, and columns 11 and 12 contain the low-order address byte. + + 13 to 44 Contain the specifications for up to 15 bytes of data. + + 45 to 46 Contain a checksum for the record. To calculate this, take the + sum of the values of all bytes from the byte count up to the + last data byte, inclusive, modulo 256. Subtract this result + from 255. + + +***************************************************************************************** + +Record Count Record (S5) + + + The record count record verifies the number of data records preceding it. Figure 4 + shows the format for such a record. The columns shown in the figure represent half + of a byte (4 bits). + + -------------------------------------- + | 1 2 3 4 5 6 7 8 9 10 | + | | + | S ID byte # of data checksum | + | count records | + -------------------------------------- + Figure 4: Record Count Record Format + + Column Description + + 1 Contains the ASCII character S, which indicates the start of + a record in Motorola S-record format. + + 2 Contains the ASCII character 5, which indicates a record + count record. + + 3 to 4 Contain the byte count, ASCII string 03. + + 5 to 8 Contain the number of data records in this file. The high- + order byte is in columns 5 and 6. + + 9 to 10 Contain the checksum for the record. + + Example: + + S503010DEE + + The example above shows a record count record indicating a total of 269 records + (0x010D) and a checksum of 0xEE. + + + +***************************************************************************************** + +Terminator Record for 32-bit address (S7) + + A terminator record specifies the end of the data records. Figure 5 shows the + format for such a record. The columns shown in the figure represent half of a byte + (4 bits). + + ------------------------------------- + | 1 2 3 4 5...12 13 14 | + | | + | S ID byte load checksum | + | count address | + ------------------------------------- + Figure5: Terminator Record Format for 32-Bit Load Address + + Column Description + + 1 Contains the ASCII character S, which indicates the start of + a record in Motorola S-record format. + + 2 Contains the ASCII character 7, which indicates a 32-bit + load address. + + 3 to 4 Contain the byte count, ASCII string 04. + + 5 to 12 Contain the load address that is either set to zero or to the + starting address specified in the END directive or START + command (there are no data bytes). + + 13 to 14 Contain the checksum for the record. + +***************************************************************************************** + +Terminator Record for 24-bit address (S8) + + + A terminator record specifies the end of the data records. Figure 6 shows the + format for such a record. The columns shown in the figure represent half of a byte + (4 bits). + + ---------------------------------------- + | 1 2 3 4 5 6 7 8 9 10 11 12 | + | | + | S ID byte load checksum | + | count address | + ---------------------------------------- + Figure 6: Terminator Record Format for 24-Bit Load Address + + Column Description + + 1 Contains the ASCII character S, which indicates the start of + a record in Motorola S-record format. + + 2 Contains the ASCII character 8, which indicates a 24-bit + load address. + + 3 to 4 Contain the byte count, ASCII string 04. + + 5 to 10 Contain the load address, which is either set to zero or to the + starting address specified in the END directive or START + command. There are no data bytes. + + 11 to 12 Contain the checksum for the record. + + Example: + + S804000AF0001 + + The previous example shows a terminator record with a 24-bit load address of + 0x000AF0 and a checksum of 0x01. + + +***************************************************************************************** + +Terminator Record for 16-bit address (S9) + + + A terminator record specifies the end of the data records. Figure 7 shows the + format for such a record. The columns shown in the figure represent half of a byte + (4 bits). + + ------------------------------------- + | 1 2 3 4 5 6 7 8 9 10 | + | | + | S ID byte load checksum | + | count address | + ------------------------------------- + Figure 7: Terminator Record Format for 16-Bit Load Address + + + Column Description + + 1 Contains the ASCII character S, which indicates the start of + a record in Motorola S-record format. + + 2 Contains the ASCII character 9, which indicates a 16-bit + load address. + + 3 to 4 Contain the byte count, ASCII string 04. + + 5 to 8 Contain the load address, which is either set to zero or to the + starting address specified in the END directive or START + command (there are no data bytes). + + 9 to 10 Contain the checksum for the record. + + + +***************************************************************************************** + hagen.v.tronje@on-line.de diff --git a/tools/hex2bin-2.0/doc/formats.txt b/tools/hex2bin-2.0/doc/formats.txt new file mode 100644 index 0000000..25e5e37 --- /dev/null +++ b/tools/hex2bin-2.0/doc/formats.txt @@ -0,0 +1,72 @@ +Hex formats + +Intel +===== + +Hexadecimal values are always in uppercase. Each line is a record. +The sum of all the bytes in each record should be 00 (modulo 256). + +Record types: + +00: data records +01: end-of-file record +02: extended address record + +Data record +----------- + + :0D011C0000000000C3E0FF0000000000C30F + +: 0D 011C 00 00000000C3E0FF0000000000C3 0F +| | | | -------------+------------ | +| | | | | +--- Checksum +| | | | +------------------ Data bytes +| | | +--------------------------------- Record type +| | +------------------------------------- Address +| +----------------------------------------- Number of data bytes ++-------------------------------------------- Start of record + + +End of file record +------------------ + + :00000001FE + +: 00 0000 01 FE +| | | | | +| | | | +--- Checksum +| | | +------ Record type +| | +---------- Address +| +-------------- Number of data bytes ++----------------- Start of record + + + +Extended address record +----------------------- + + :02010002E0001B + +: 02 0100 02 E000 1B +| | | | | | +| | | | | +--- Checksum +| | | | +-------- Segment address +| | | +----------- Record type +| | +--------------- Address +| +------------------- Number of data bytes ++---------------------- Start of record + +Following data records will start at E000:0100 or E0100 + + + + + + + + + + + + + diff --git a/tools/hex2bin-2.0/doc/intelhex.spc b/tools/hex2bin-2.0/doc/intelhex.spc new file mode 100644 index 0000000..946d586 --- /dev/null +++ b/tools/hex2bin-2.0/doc/intelhex.spc @@ -0,0 +1,409 @@ + +====================================================================== + +Intel +Hexadecimal Object File +Format Specification +Revision A, 1/6/88 + + + +DISCLAIMER + +Intel makes no representation or warranties with respect to the contents +hereof and specifically disclaims any implied warranties of +merchantability or fitness for any particular purpose. Further, Intel +reserves the right to revise this publication from time to time in the +content hereof without obligation of Intel to notify any person of such +revision or changes. The publication of this specification should not +be construed as a commitment on Intel's part to implement any product. + + +1. Introduction +This document describes the hexadecimal object file format for the Intel +8- bit, 16-bit, and 32-bit microprocessors. The hexadecimal format is +suitable as input to PROM programmers or hardware emulators. +Hexadecimal object file format is a way of representing an absolute +binary object file in ASCII. Because the file is in ASCII instead of +binary, it is possible to store the file is non-binary medium such as +paper-tape, punch cards, etc.; and the file can also be displayed on CRT +terminals, line printers, etc.. The 8-bit hexadecimal object file +format allows for the placement of code and data within the 16-bit +linear address space of the Intel 8-bit processors. The 16-bit +hexadecimal format allows for the 20-bit segmented address space of the +Intel 16-bit processors. And the 32-bit format allows for the 32-bit +linear address space of the Intel 32-bit processors. +The hexadecimal representation of binary is coded in ASCII alphanumeric +characters. For example, the 8-bit binary value 0011-1111 is 3F in +hexadecimal. To code this in ASCII, one 8-bit byte containing the ASCII +code for the character '3' (0011-0011 or 033H) and one 8-bit byte +containing the ASCII code for the character 'F' (0100-0110 or 046H) are +required. For each byte value, the high-order hexadecimal digit is +always the first digit of the pair of hexadecimal digits. This +representation (ASCII hexadecimal) requires twice as ma ny bytes as the +binary representation. +A hexadecimal object file is blocked into records, each of which +contains the record type, length, memory load address and checksum in +addition to the data. There are currently six (6) different types of +records that are defined, not all combinations of these records are +meaningful, however. The records are: + +Data Record (8-, 16-, or 32-bit formats) +End of File Record (8-, 16-, or 32-bit formats) +Extended Segment Address Record (16- or 32-bit formats) +Start Segment Address Record (16- or 32-bit formats) +Extended Linear Address Record (32-bit format only) +Start Linear Address Record (32-bit format only) + + +2. General Record Format +| RECORD | LOAD | | | INFO | | +| MARK | RECLEN | OFFSET | RECTYP | or | CHKSUM | +| ':' | | | | DATA | | + 1-byte 1-byte 2-bytes 1-byte n-bytes 1-byte + +Each record begins with a RECORD MARK field containing 03AH, the ASCII +code for the colon (':') character. +Each record has a RECLEN field which specifies the number of bytes of +information or data which follows the RECTYP field of the record. Note +that one data byte is represented by two ASCII characters. The maximum +value of the RECLEN field is hexadecimal 'FF' or 255. +Each record has a LOAD OFFSET field which specifies the 16-bit starting +load offset of the data bytes, therefore this field is only used for +Data Records. In other records where this field is not used, it should +be coded as four ASCII zero characters ('0000' or 030303030H). +Each record has a RECTYP field which specifies the record type of this +record. The RECTYP field is used to interpret the remaining information +within the record. The encoding for all the current record types are: + +'00' Data Record +'01' End of File Record +'02' Extended Segment Address Record +'03' Start Segment Address Record +'04' Extended Linear Address Record +'05' Start Linear Address Record + +Each record has a variable length INFO/DATA field, it consists of zero +or more bytes encoded as pairs of hexadecimal digits. The +interpretation of this field depends on the RECTYP field. +Each record ends with a CHKSUM field that contains the ASCII hexadecimal +representation of the two's complement of the 8-bit bytes that result +from converting each pair of ASCII hexadecimal digits to one byte of +binary, from and including the RECLEN field to and including the last +byte of the INFO/DATA field. Therefore, the sum of all the ASCII pairs +in a record after converting to binary, from the RECLEN field to and +including the CHKSUM field, is zero. + + +3. Extended Linear Address Record (32-bit format only) +| RECORD | LOAD | | | | | +| MARK | RECLEN | OFFSET | RECTYP | ULBA | CHKSUM | +| ':' | '02' | '0000' | '04' | | | + 1-byte 1-byte 2-bytes 1-byte 2-bytes 1-byte + +The 32-bit Extended Linear Address Record is used to specify bits 16-31 +of the Linear Base Address (LBA), where bits 0-15 of the LBA are zero. +Bits 16-31 of the LBA are referred to as the Upper Linear Base Address +(ULBA). The absolute memory address of a content byte in a subsequent +Data Record is obtained by adding the LBA to an offset calculated by +adding the LOAD OFFSET field of the containing Data Record to the index +of the byte in the Data Record (0, 1, 2, ... n). This offset addition +is done modulo 4G (i.e., 32-bits), ignoring any carry, so that offset +wrap-around loading (from OFFFFFFFFH to OOOOOOOOOH) results in wrapping +around from the end to the beginning of the 4G linear address defined by +the LBA. The linear address at which a particular byte is loaded is +calculated as: +(LBA + DRLO + DRI) MOD 4G +where: +DRLO is the LOAD OFFSET field of a Data Record. +DRI is the data byte index within the Data Record. + +When an Extended Linear Address Record defines the value of LBA, it may +appear anywhere within a 32-bit hexadecimal object file. This value +remains in effect until another Extended Linear Address Record is +encountered. The LBA defaults to zero until an Extended Linear Address +Record is encountered. +The contents of the individual fields within the record are: + +RECORD MARK +This field contains 03AH, the hexadecimal encoding of the ASCII colon +(':') character. + +RECLEN +The field contains 03032H, the hexadecimal encoding of the ASCII +characters '02', which is the length, in bytes, of the ULBA data +information within this record. + +LOAD OFFSET +This field contains 030303030H, the hexadecimal encoding of the ASCII +characters '0000', since this field is not used for this record. + +RECTYP +This field contains 03034H, the hexadecimal encoding of the ASCII +character '04', which specifies the record type to be an Extended Linear +Address Record. + +ULBA +This field contains four ASCII hexadecimal digits that specify the +16-bit Upper Linear Base Address value. The high-order byte is the +10th/llth character pair of the record. The low-order byte is the +12th/13th character pair of the record. + +CHKSUM +This field contains the check sum on the RECLEN, LOAD OFFSET, RECTYP, +and ULBA fields. + + +4. Extended Segment Address Record (16- or 32-bit formats) +| RECORD | LOAD | | | | | +| MARK | RECLEN | OFFSET | RECTYP | USBA | CHKSUM | +| ':' | '02' | '0000' | '02' | | | + 1-byte 1-byte 2-bytes 1-byte 2-bytes 1-byte + +The 16-bit Extended Segment Address Record is used to specify bits 4-19 +of the Segment Base Address (SBA), where bits 0-3 of the SBA are zero. +Bits 4-19 of the SBA are referred to as the Upper Segment Base Address +(USBA). The absolute memory address of a content byte in a subsequent +Data Record is obtained by adding the SBA to an offset calculated by +adding the LOAD OFFSET field of the containing Data Record to the index +of the byte in the Data Record (0, 1, 2, ... n). This offset addition +is done modulo 64K (i.e., 16-bits), ignoring any carry, so that offset +wraparound loading (from OFFFFH to OOOOOH) results in wrapping around +from the end to the beginning of the 64K segment defined by the SBA. +The address at which a particular byte is loaded is calculated as: + + SBA + ([DRLO + DRI] MOD 64K) + +where: + DRLO is the LOAD OFFSET field of a Data Record. + DRI is the data byte index within the Data Record. + +When an Extended Segment Address Record defines the value of SBA, it +may appear anywhere within a 16-bit hexadecimal object file. This +value remains in effect until another Extended Segment Address +Record is encountered. The SBA defaults to zero until an Extended +Segment Address Record is encountered. + +The contents of the individual fields within the record are: + +RECORD MARK +This field contains 03AH, the hexadecimal encoding of the ASCII +colon (':') character. + +RECLEN +The field contains 03032H, the hexadecimal encoding of the ASCII +characters '02', which is the length, in bytes, of the USBA data +information within this record. + +LOAD OFFSET +This field contains 030303030H, the hexadecimal encoding of the +ASCII characters '0000', since this field is not used for this +record. + +RECTYP +This field contains 03032H, the hexadecimal encoding of the ASCII +character '02', which specifies the record type to be an Extended +Segment Address Record. + +USBA +This field contains four ASCII hexadecimal digits that specify the +16-bit Upper Segment Base Address value. The high-order byte is the +10th/1lth character pair of the record. The low-order byte is the +12th/13th character pair of the record. + +CHKSUM +This field contains the check sum on the RECLEN, LOAD OFFSET, +RECTYP, and USBA fields. + +5. Data Record (8-, 16-, or 32-bit formats) + +| RECORD | LOAD | | | | | +| MARK | RECLEN | OFFSET | RECTYP | DATA | CHKSUM | +| ':' | | | '00' | | | + 1-byte 1-byte 2-bytes 1-byte n-bytes 1-byte + + +The Data Record provides a set of hexadecimal digits that represent +the ASCII code for data bytes that make up a portion of a memory +image. The method for calculating the absolute address (linear in +the 8-bit and 32-bit case and segmented in the 16-bit case) for each +byte of data is described in the discussions of the Extended Linear +Address Record and the Extended Segment Address Record. + +The contents of the individual fields within the record are: + +RECORD MARK +This field contains 03AH, the hexadecimal encoding of the ASCII +colon (':') character. + +RECLEN +The field contains two ASCII hexadecimal digits that specify the +number of data bytes in the record. The maximum value is 'FF' or +04646H (255 decimal). + +LOAD OFFSET +This field contains four ASCII hexadecimal digits representing the +offset from the LBA (see Extended Linear Address Record) or SBA (see +Extended Segment Address Record) defining the address which the +first byte of the data is to be placed. + +RECTYP +This field contains 03030H, the hexadecimal encoding of the ASCII +character '00', which specifies the record type to be a Data Record. + +DATA +This field contains pairs of ASCII hexadecimal digits, one pair for +each data byte. + +CHKSUM +This field contains the check sum on the RECLEN, LOAD OFFSET, +RECTYP, and DATA fields. + + +6. Start Linear Address Record (32-bit format only) + +| RECORD | LOAD | | | | | +| MARK | RECLEN | OFFSET | RECTYP | EIP | CHKSUM | +| ':' | '04' | '0000' | '05' | | | + 1-byte 1-byte 2-bytes 1-byte 4-bytes 1-byte + + +The Start Linear Address Record is used to specify the execution +start address for the object file. The value given is the 32-bit +linear address for the EIP register. Note that this record only +specifies the code address within the 32-bit linear address space of +the 80386. If the code is to start execution in the real mode of +the 80386, then the Start Segment Address Record should be used +instead, since that record specifies both the CS and IP register +contents necessary for real mode. + +The Start Linear Address Record can appear anywhere in a 32-bit +hexadecimal object file. If such a record is not present in a +hexadecimal object file, a loader is free to assign a default start +address. + +The contents of the individual fields within the record are: + +RECORD MARK +This field contains 03AH, the hexadecimal encoding of the ASCII +colon (':') character. + +RECLEN +The field contains 03034H, the hexadecimal encoding of the ASCII +characters '04', which is the length, in bytes, of the EIP register +content within this record. + +LOAD OFFSET +This field contains 030303030H, the hexadecimal encoding of the +ASCII characters '0000', since this field is not used for this +record. + +RECTYP +This field contains 03035H, the hexadecimal encoding of the ASCII +character '05', which specifies the record type to be a Start Linear +Address Record. + +EIP +This field contains eight ASCII hexadecimal digits that specify the +32-bit EIP register contents. The high-order byte is the 10th/1lth +character pair. + +CHKSUM +This field contains the check sum on the RECLEN, LOAD OFFSET, +RECTYP, and EIP fields. + + +7. Start Segment Address Record (16- or 32-bit formats) + +| RECORD | LOAD | | | | | +| MARK | RECLEN | OFFSET | RECTYP | CS/IP | CHKSUM | +| ':' | '04' | '0000' | '03' | | | + 1-byte 1-byte 2-bytes 1-byte 4-bytes 1-byte + + +The Start Segment Address Record is used to specify the execution +start address for the object file. The value given is the 20-bit +segment address for the CS and IP registers. Note that this record +only specifies the code address within the 20-bit segmented address +space of the 8086/80186. + +The Start Segment Address Record can appear anywhere in a 16-bit +hexadecimal object file. If such a record is not present in a +hexadecimal object file, a loader is free to assign a default start +address. + +The contents of the individual fields within the record are: + +RECORD MARK +This field contains 03AH, the hexadecimal encoding of the ASCII +colon (':') character. + +RECLEN +The field contains 03034H, the hexadecimal encoding of the ASCII +characters '04', which is the length, in bytes, of the CS/IP +register contents within this record. + +LOAD OFFSET +This field contains 030303030H, the hexadecimal encoding of the +ASCII characters '0000', since this field is not used for this +record. + +RECTYP +This field contains 03033H, the hexadecimal encoding of the ASCII +character '03', which specifies the record type to be a Start +Segment Address Record. + +CS/IP +This field contains eight ASCII hexadecimal digits that specify the +16-bit CS register and 16-bit IP register contents. The high-order +byte of the CS register content is the 10th/llth character pair, the +low-order byte is the 12th/13th character pair of the record. The +high-order byte of the IP register content is the 14th/15th +character pair, the low-order byte is the 16th/17th character pair +of the record. + +CHKSUM +This field contains the check sum on the RECLEN, LOAD OFFSET, +RECTYP, and CS/IP fields. + + + +8. End of File Record (8-, 16-, or 32-bit formats) + +| RECORD | LOAD | | | | +| MARK | RECLEN | OFFSET | RECTYP | CHKSUM | +| ':' | '00' | '0000' | '01' | | + 1-byte 1-byte 2-bytes 1-byte 1-byte + +The End of File Record specifies the end of the hexadecimal object +file. + +The contents of the individual fields within the record are: + +RECORD MARK +This field contains 03AH, the hexadecimal encoding of the ASCII +colon (':') character. + +RECLEN +The field contains 03030H, the hexadecimal encoding of the ASCII +characters '00'. Since this record does not contain any INFO/DATA +bytes, the length is zero. + +LOAD OFFSET +This field contains 030303030H, the hexadecimal encoding of the +ASCII characters '0000', since this field is not used for this +record. + +RECTYP +This field contains 03031H, the hexadecimal encoding of the ASCII +character '01', which specifies the record type to be an End of File +Record. + +CHKSUM +This field contains the check sum an the RECLEN, LOAD OFFSET, and +RECTYP fields. Since all the fields are static, the check sum can +also be calculated statically, and the value is 04646H, the +hexadecimal encoding of the ASCII characters 'FF'. + +======================================================================== +END diff --git a/tools/hex2bin-2.0/doc/srec.txt b/tools/hex2bin-2.0/doc/srec.txt new file mode 100644 index 0000000..ea63d31 --- /dev/null +++ b/tools/hex2bin-2.0/doc/srec.txt @@ -0,0 +1,447 @@ +S-Records + + + -S-Record Format- + + Chaplin@keinstr.uucp (Roger Chaplin) reposted an article written + by mcdchg!motmpl!ron (Ron Widell) that explained how Motorola + S-Records are formatted. This comes from a unix man page. No + mention of which version of Unix is specified. This section + of the FAQ is a bit long. An anonymous ftp archive is currently + being sought. When one is found, the section will be placed in + the archive. + + + SREC(4) UNIX 5.0 (03/21/84) SREC(4) + + + An S-record file consists of a sequence of specially formatted + ASCII character strings. An S-record will be less than or equal to + 78 bytes in length. + + The order of S-records within a file is of no significance and no + particular order may be assumed. + + The general format of an S-record follow: + + +------------------//-------------------//-----------------------+ + | type | count | address | data | checksum | + +------------------//-------------------//-----------------------+ + + type A char-2- field. These characters describe the + type of record (S0, S1, S2, S3, S5, S7, S8, or + S9). + count A char-2- field. These characters when paired and + interpreted as a hexadecimal value, display the + count of remaining character pairs in the record. + + address A char-4,6, or 8- field. These characters grouped + and interpreted as a hexadecimal value, display + the address at which the data field is to be + loaded into memory. The length of the field + depends on the number of bytes necessary to hold + the address. A 2-byte address uses 4 characters, + a 3-byte address uses 6 characters, and a 4-byte + address uses 8 characters. + data A char -0-64- field. These characters when paired + and interpreted as hexadecimal values represent + the memory loadable data or descriptive + information. + + checksum A char-2- field. These characters when paired and + interpreted as a hexadecimal value display the + least significant byte of the ones complement of + the sum of the byte values represented by the + pairs of characters making up the count, the + address, and the data fields. + + Each record is terminated with a line feed. If any + additional or different record terminator(s) or delay + characters are needed during transmission to the target + system it is the responsibility of the transmitting program + to provide them. + + S0 Record The type of record is 'S0' (0x5330). The address + + + field is unused and will be filled with zeros + (0x0000). The header information within the data + field is divided into the following subfields. + + mname is char-20- and is the + module name. + ver is char-2- and is the + version number. + + rev is char-2- and is the + revision number. + description is char-0-36- and is a + text comment. + + Each of the subfields is composed of ASCII bytes + whose associated characters, when paired, + represent one byte hexadecimal values in the case + of the version and revision numbers, or represent + the hexadecimal values of the ASCII characters + comprising the module name and description. + + S1 Record The type of record field is 'S1' (0x5331). The + address field is interpreted as a 2-byte address. + The data field is composed of memory loadable + data. + S2 Record The type of record field is 'S2' (0x5332). The + address field is interpreted as a 3-byte address. + The data field is composed of memory loadable + data. + + S3 Record The type of record field is 'S3' (0x5333). The + address field is interpreted as a 4-byte address. + The data field is composed of memory loadable + data. + S5 Record The type of record field is 'S5' (0x5335). The + address field is interpreted as a 2-byte value + and contains the count of S1, S2, and S3 records + previously transmitted. There is no data field. + + S7 Record The type of record field is 'S7' (0x5337). The + address field contains the starting execution + address and is interpreted as 4-byte address. + There is no data field. + S8 Record The type of record field is 'S8' (0x5338). The + address field contains the starting execution + address and is interpreted as 3-byte address. + There is no data field. + + S9 Record The type of record field is 'S9' (0x5339). The + address field contains the starting execution + address and is interpreted as 2-byte address. + There is no data field. + + EXAMPLE + + Shown below is a typical S-record format file. + + S00600004844521B + S1130000285F245F2212226A000424290008237C2A + S11300100002000800082629001853812341001813 + S113002041E900084E42234300182342000824A952 + S107003000144ED492 + S5030004F8 + S9030000FC + + The file consists of one S0 record, four S1 records, one S5 + record and an S9 record. + + The S0 record is comprised as follows: + + S0 S-record type S0, indicating it is a header + record. + 06 Hexadecimal 06 (decimal 6), indicating that six + character pairs (or ASCII bytes) follow. + + 00 00 Four character 2-byte address field, zeroes in + this example. + 48 ASCII H, D, and R - "HDR". + + 1B The checksum. + + The first S1 record is comprised as follows: + S1 S-record type S1, indicating it is a data record + to be loaded at a 2-byte address. + + 13 Hexadecimal 13 (decimal 19), indicating that + nineteen character pairs, representing a 2 byte + address, 16 bytes of binary data, and a 1 byte + checksum, follow. + 00 00 Four character 2-byte address field; hexadecimal + address 0x0000, where the data which follows is to + be loaded. + + 28 5F 24 5F 22 12 22 6A 00 04 24 29 00 08 23 7C Sixteen + character pairs representing the actual binary + data. + 2A The checksum. + + The second and third S1 records each contain 0x13 (19) + character pairs and are ended with checksums of 13 and 52, + respectively. The fourth S1 record contains 07 character + pairs and has a checksum of 92. + + The S5 record is comprised as follows: + + S5 S-record type S5, indicating it is a count record + indicating the number of S1 records. + + + + 03 Hexadecimal 03 (decimal 3), indicating that three + character pairs follow. + + 00 04 Hexadecimal 0004 (decimal 4), indicating that + there are four data records previous to this + record. + F8 The checksum. + + The S9 record is comprised as follows: + + S9 S-record type S9, indicating it is a termination + record. + 03 Hexadecimal 03 (decimal 3), indicating that three + character pairs follow. + + 00 00 The address field, hexadecimal 0 (decimal 0) + indicating the starting execution address. + FC The checksum. + + + -Intel Hex ASCII Format- + + Intel HEX-ASCII format takes the form: + + +----------------------------------- Start Character + | + | +-------------------------------- Byte Count + | | (# of data bytes) + | | + | | +-------------------------- Address of first data. + | | | + | | | +-------------------- Record Type (00 data, + | | | | 01 end of record) + | | | | + | | | | +------------ Data Bytes + | | | | | + | | | | | +---- Checksum + | | | | | | + | / \ / \ / \ / \ / \ + : B C A A A A T T H H ... H H C C + + An examples: + + :10000000DB00E60F5F1600211100197ED300C3004C + :1000100000000101030307070F0F1F1F3F3F7F7FF2 + :01002000FFE0 + :00000001FF + + This information comes from _Microprocessors and Programmed + Logic_, Second Edition, Kenneth L. Short, 1987, Prentice-Hall, + ISBN 0-13-580606-2. + + Provisions have been made for data spaces larger than 64 kBytes. + The above reference does not discuss them. I suspect there is + a start of segment type record, but I do not know how it is + implemented. + +---------------------------------------------------------------------------- + +/* This file contains source code to read a Motorola S-record file into +** a memory image. The size of the file cannot exceed BUFSIZE of data. +** The image is then written to disk either as binary data starting at +** address 0 with no data gaps, or as a C array of unsigned longs. +** Input lines must be no longer than MAXLINE. No check is made! +** +** Author: Eric McRae, Electro-Logic Machines, Inc. +** Date: Copyright 1994 +** +** This source code is made available to the public "as is". No +** warranty is given or implied for it's proper operation. This source +** code may be used in whole or in part as long as this copyright is +** included. +*/ +#include +#include +#include + +/* Comment the following line for non PC applications */ +#define PCDOS + +/* Uncomment the following line if you want a binary output instead of +** a structure +*/ +/* #define BINARY */ + +#ifdef PCDOS /* Intel x86 architecture */ +#define BUFSIZE 49152 /* 48K to avoid segment hopping */ +#else /* Any reasonable (non-segmented) arch... */ +#define BUFSIZE 65536 /* As big as you want */ +#endif + +#define MAXLINE 256 /* Length of longest input line + 1 */ +/* Globals */ +FILE *infilePH, *outfilePH; /* Handles for input and output files */ +unsigned char *bufAC, /* Allocated image buffer */ + *highestPC = NULL; /* Highest buffer address written */ + +/* Change this string to reflect the name of the output array */ +char headerAC[] = "unsigned long sRec[] =\n{\n"; + +/* Predeclarations */ +int parsebufN( char * ); /* Does the actual parsing */ + +void main(int argc, const char * argv[]) +{ + int c, /* Temp char storage */ + resN; /* result status */ + char *lbufPC, lbufAC[MAXLINE]; + int linectrN = 0; /* Used to correlate parse fail to input line */ + +#ifndef BINARY + int i; + unsigned long *codePL; + unsigned char *codePC; +#endif + + /* Check the argument count */ + if( argc != 3 ) /* If didn't specify input and output files */ + { + printf("Usage: %s: infile outfile\n", argv[0] ); + exit(1); + } + + /* OK, let's open some files */ + if( ( infilePH = fopen( argv[1], "r" ) )== NULL ) + { + printf("%s: Couldn't open input file %s\n", argv[0], argv[1] ); + exit(2); + } + + if( ( outfilePH = fopen( argv[2], "w" ) ) == NULL ) + { + printf("%s: Couldn't open output file %s\n", argv[0], argv[3] ); + exit(3); + } + + /* OK, get a buffer and clear it. */ + if( (bufAC = calloc( (size_t)BUFSIZE, (size_t)1 )) == NULL ) + { + printf("%s: Couldn't malloc memory for buffer\n", argv[0] ); + exit(4); + } + + lbufPC = lbufAC; /* Point at beginning of line buffer */ + while( c = fgetc( infilePH )) + { + if( (c == '\n') || (c == EOF) ) /* If found end of line or file */ + { /* Parse the Line */ + if( ( c == EOF ) && ( ferror( infilePH ) ) ) + { + printf("%s: Error reading input file\n", argv[0] ); + exit(5); + } + else + { /* OK, have a complete line in buffer */ + linectrN++; /* Increment line counter */ + if( lbufPC == lbufAC ) + break; /* ignore blank lines */ + *lbufPC = 0; /* Terminate the line string */ + if( resN = parsebufN( lbufAC ) ) /* Parse data record to mem */ + { + printf("%s: Error reading input file at line %d, return code = %d\n", + argv[0], linectrN, resN ); + exit( resN ); + } + lbufPC = lbufAC; /* Repoint line buffer pointer */ + } /* End of have a complete line */ + } + else + *lbufPC++ = c; /* Place char into line buffer */ + } + + /* At this point, the input file has been emptied. Now dispose of the + ** output data according to compilation mode. + */ + +#ifdef BINARY + + /* Write the buffer back to disk as a binary image */ + resN = fwrite( bufAC, 1, (size_t)((highestPC - bufAC) + 1), outfilePH ); + if( resN != (int)( (highestPC - bufAC) + 1) ) + { + printf("%s: Error writing output file\n", argv[0] ); + exit( 6 ); + } + +#else + /* Produce a file that can be included in a C program. Data is read + ** from buffer as bytes to avoid portability/endian problems with + ** this program. + */ + /* Output header first, then 1 long per line */ + fwrite( (void *)headerAC, 1, (size_t)(sizeof( headerAC )-1), outfilePH ); + + codePL = (unsigned long *)bufAC; + for( i = (highestPC - bufAC + 1) / 4; i; i-- ) /* for each long */ + { + codePC = (unsigned char *)codePL++; + sprintf(lbufAC, "0x%02x%02x%02x%02x%s", + *codePC, *(codePC + 1), *(codePC + 2), *(codePC + 3), + i == 1 ? "\n" : ",\n" ); /* No comma after final long */ + fwrite( lbufAC, 1, (size_t)(strlen( lbufAC )), outfilePH ); + } + /* OK, data has been written out, close end of array */ + fwrite( "};\n", 1, (size_t)3, outfilePH ); +#endif +} + +/* Function: parsebufV +** Parses an S-record in the buffer and writes it into the buffer +** if it is has a valid checksum. +** +** Args: pointer to character buffer for null terminated line +** Returns: int result code: 0 = success, else failure +*/ +int parsebufN( char *lbufPC ) +{ + unsigned long addrL; + unsigned char cksmB, /* checksum of addr, count, & data length */ + *bufPC; /* Pointer into memory array */ + int i, countN, /* Number of bytes represented in record */ + oheadN, /* Number of overhead (addr + chksum) bytes */ + tvalN; /* Temp for check checksum */ + + switch( *(lbufPC+1) ) /* examine 2nd character on the line */ + { + case '1': /* 16 bit address field */ + if( sscanf(lbufPC, "S1%2x%4lx", &countN, &addrL ) != 2 ) + return( 10 ); /* Flag error in S1 record */ + oheadN = 3; /* 2 address + 1 checksum */ + break; + + case '2': /* 24 bit address field */ + if( sscanf(lbufPC, "S2%2x%6lx", &countN, &addrL ) != 2 ) + return( 11 ); /* Flag error in S2 record */ + oheadN = 4; /* 3 address + 1 checksum */ + break; + + case '3': /* 32 bit address field */ + if( sscanf(lbufPC, "S3%2x%8lx", &countN, &addrL ) != 2 ) + return( 12 ); /* Flag error in S3 record */ + oheadN = 5; /* 4 address + 1 checksum */ + break; + + default: /* ignore all but S1,2,3 records. */ + return( 0 ); + } + + if( addrL > BUFSIZE ) return( 13 ); /* if address exceeds buffer size */ + bufPC = bufAC + addrL; /* otherwise, point to right spot in buffer */ + + /* OK now see if checksum is OK, while reading data to buffer */ + cksmB = 0; + countN++; /* Bump counter to read final checksum too */ + for( i = 1; i <= countN; i++ ) + { + sscanf( lbufPC + i*2, "%2x", &tvalN ); /* Scan a 2 hex digit byte */ + cksmB += (unsigned char)tvalN; + if( ( i > oheadN ) && ( i < countN ) ) /* If scanned a data byte */ + *bufPC++ = (unsigned char) tvalN; /* write it to the buffer */ + } + if( cksmB += 1 ) return( 14 ); /* flag checksum error */ + + if( (bufPC - 1) > highestPC ) + highestPC = bufPC - 1; /* track highest address loaded */ + + return( 0 ); /* Successful return */ +} + + + -- cgit v1.2.3