SREC (file format)

Overview

The S-record format was created in the mid-1970s for the Motorola 6800 processor. Software development tools for that and other embedded processors would make executable code and data in the S-record format. PROM programmers would then read the S-record format and "burn" the data into the PROMs or EPROMs used in the embedded system.

Other hex formats

There are other ASCII encoding with a similar purpose. BPNF, BHLF, and B10F were early binary formats, but they are neither compact nor flexible. Hexadecimal formats are more compact because they represent 4 bits rather than 1 bit per character. Many, such as S-record, are more flexible because they include address information so they can specify just a portion of a PROM. Intel HEX format was often used with Intel processors. Tek Hex is another hex format that can include a symbol table for debugging.

Record structure

An SREC format file consists of a series of ASCII text records. The records have the following structure from left to right:

1. Record type, two characters, an uppercase "S" (0x53) then a numeric digit 0 to 9, defining the type of record.
2. Byte count, two hex digits, indicating the number of bytes (hex digit pairs) that follow in the rest of the record (address + data + checksum). This field has a minimum value of 3 for 16-bit address field plus 1 checksum byte, and a maximum value of 255 (0xFF).
3. Address, four / six / eight hex digits as determined by the record type. The address bytes are arranged in big endian format.
4. Data, a sequence of 2n hex digits, for n bytes of the data. For S1/S2/S3 records, a maximum of 32 bytes per record is typical since it will fit on an 80 character wide terminal screen, though 16 bytes would be easier to visually decode each byte at a specific address.
5. Checksum, two hex digits, the least significant byte of ones' complement of the sum of the values represented by the two hex digit pairs for the byte count, address and data fields. See example section for a detailed checksum example.

Text line terminators

SREC records are separated by one or more ASCII line termination characters so that each record appears alone on a text line. This enhances legibility by visually delimiting the records and it also provides padding between records that can be used to improve machine parsing efficiency.

Programs that create HEX records typically use line termination characters that conform to the conventions of their operating systems. For example, Linux programs use a single LF (line feed, hex value 0A) character to terminate lines, whereas Windows programs use a CR (carriage return, hex value 0D) followed by a LF.

Record types

The following table describes 10 possible S-records. S4 is reserved and not currently defined. S6 was originally reserved but was later redefined at some point.

Record order

Although some Unix documentation states "the order of S-records within a file is of no significance and no particular order may be assumed", in practice most software has ordered the SREC records. The typical record order starts with a (sometimes optional) S0 header record, continues with a sequence of one or more S1/S2/S3 data records, may have one optional S5/S6 count record, and ends with one appropriate S7/S8/S9 termination record.

1. S0
2. S1 (one or more records)
3. S5 (optional record)
4. S9

1. S0
2. S2 (one or more records)
3. S5 (optional record)
4. S8

1. S0
2. S3 (one or more records)
3. S5 (optional record)
4. S7

Limitations

Record length - Unix manual page documentation states, "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 manual page further limits the number of characters in the data field to 64 (or 32 data bytes). A record with an 8-hex-character address and 64 data characters would be 78 (2+2+8+64+2) characters long (this count ignores possible end-of-line or string termination characters). The file could be printed on an 80-character wide teleprinter. A note at the bottom of the manual page states, "This [manual page] is the only place that a 78-byte limit on total record length or 64-byte limit on data length is documented. These values shouldn't be trusted for the general case." If that limitation is ignored, the maximum length of an S-record is 514 characters: 2 for Record Type field + 2 for Byte Count field (whose value would be 0xFF=255) + 2*255 for Address, Data, and Checksum fields. Additional buffer space may be required for the line and string terminators. Using long line lengths has problems: "The Motorola S-record format definition permits up to 255 bytes of payload, or lines of 514 characters, plus the line termination. All EPROM programmers should have sufficiently large line buffers to cope with records this big. Few do."

Data field - Some documentation recommends a maximum of 32 bytes of data (64 hex characters) in this field. The minimum amount of data for S0/S1/S2/S3 records is zero. The maximum amount of data varies depending on the size of the address field. Since the Byte Count field can't be higher than 255 (0xFF), then the maximum number of bytes of data is calculated by 255 minus (1 byte for checksum field) minus (number of bytes in the address field). S0/S1 records support up to 252 bytes of data. S2 record supports up to 251 bytes of data. S3 record supports up to 250 bytes of data.

Comments - The SREC file format does not support comments. Some software ignores all text lines that do not start with "S" and ignores all text after the checksum field; that extra text is sometimes used (incompatibly) for comments. For example, the CCS PIC compiler supports placing a ";" comment line at the top or bottom of an Intel HEX file, and its manuals states "some programmers (MPLAB in particular) do not like comments at the top of the hex file", which is why the compiler has the option of placing the comment at the bottom of the hex file.

Examples

  Record type   Byte count   Address   Data   Checksum

Checksum calculation

The following example record:

is decoded to show how the checksum value is calculated as follows:

1. Add: add each byte 13 + 7A+F0 + 0A+0A+0D+00+00+00+00+00+00+00+00+00+00+00+00+00 = 19E (hex) total.
2. Mask: keep the least significant byte of the total = 9E (hex).
3. Complement: compute ones' complement of least significant byte = 61 (hex).

16-bit memory address