SREC (file format)

From Wikipedia, the free encyclopedia
  (Redirected from S-record)
Jump to: navigation, search
S-record
Motorola SREC Chart.png
A quick reference chart for the Motorola SREC format.
Filename extension .s19, .s28, .s37, .s, .s1, .s2, .s3, .sx, .srec, .mot

Motorola S-record is a file format, created by Motorola, that conveys binary information in ASCII hex text form. This file format may also be known as SRECORD, SREC, S19, S28, S37. It is commonly used for programming microcontrollers, EPROMs, and other types of programmable logic devices. In a typical application, a compiler or assembler converts a program's source code (such as C or assembly language) to machine code and outputs it into a HEX file. The HEX file is then imported by a programmer to "burn" the machine code into a ROM, or is transferred to the target system for loading and execution.

Overview[edit]

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[edit]

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.

Format[edit]

Record structure[edit]

S Type Byte Count Address Data Checksum

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[edit]

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[edit]

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
Field
Record
Purpose
Address
Field
Data
Field
Record
Description
S0 Header 16-bit
"0000"
Yes This record contains vendor specific ASCII text represented as a series of hex digit pairs. It is common to see the data for this record in the format of a null-terminated string. The text data can be anything including a mixture of the following information: file/module name, version/revision number, date/time, product name, vendor name, memory designator on PCB, copyright notice.
S1 Data 16-bit
Address
Yes This record contains data that starts at the 16-bit address field.[1] This record is typically used for 8-bit microcontrollers, such as AVR, PIC, 8051, 68xx, 6502, 80xx, Z80. The number of bytes of data contained in this record is "Byte Count Field" minus 3, which is 2 bytes for "16-bit Address Field" and 1 byte for "Checksum Field".
S2 Data 24-bit
Address
Yes This record contains data that starts at a 24-bit address.[1] The number of bytes of data contained in this record is "Byte Count Field" minus 4, which is 3 bytes for "24-bit Address Field" and 1 byte for "Checksum Field".
S3 Data 32-bit
Address
Yes This record contains data that starts at a 32-bit address.[1] This record is typically used for 32-bit microcontrollers, such as ARM and 680x0. The number of bytes of data contained in this record is "Byte Count Field" minus 5, which is 4 bytes for "32-bit Address Field" and 1 byte for "Checksum Field".
S4 Reserved N/A N/A This record is reserved.
S5 Count 16-bit
Count
No This optional record contains a 16-bit count of S1 / S2 / S3 records.[1] This record is used if the record count is less than or equal to 65,535 (0xFFFF), otherwise S6 record would be used.
S6 Count 24-bit
Count
No This optional record contains a 24-bit count of S1 / S2 / S3 records. This record is used if the record count is less than or equal to 16,777,215 (0xFFFFFF). If less than 65,536 (0x010000), then S5 record would be used. NOTE: This newer record is the most recent change (not sure if official).[1]
S7 Start Address
(Termination)
32-bit
Address
No This record contains the starting execution location at a 32-bit address.[1][2] This is used to terminate a series of S3 records. If a SREC file is only used to program a memory device and the execution location is ignored, then an address of zero could be used.
S8 Start Address
(Termination)
24-bit
Address
No This record contains the starting execution location at a 24-bit address.[1][2] This is used to terminate a series of S2 records. If a SREC file is only used to program a memory device and the execution location is ignored, then an address of zero could be used.
S9 Start Address
(Termination)
16-bit
Address
No This record contains the starting execution location at a 16-bit address.[1][2] This is used to terminate a series of S1 records. If a SREC file is only used to program a memory device and the execution location is ignored, then an address of zero could be used.

Record order[edit]

Quoted from old Unix documentation "the order of S-records within a file is of no significance and no particular order may be assumed",[1] though in practice most software has ordered the SREC records. The typical record order starts with a S0 record, followed by one or more S1/S2/S3 data records, then one optional S5/S6 count record, and ending with one S7/S8/S9 record.

S19-style 16-bit address records
  1. S0
  2. S1 (one or more records)
  3. S5 (optional record)
  4. S9
S28-style 24-bit address records
  1. S0
  2. S2 (one or more records)
  3. S5 (optional record)
  4. S8
S37-style 32-bit address records
  1. S0
  2. S3 (one or more records)
  3. S5 (optional record)
  4. S7

Limitations[edit]

Record length - Quoted from old Unix documentation "an S-record will be less than or equal to 78 characters in length". This is the only place that a 78-character limit on total record length is documented, though in modern practice this should be ignored.[1] Modern software functions should allocate a buffer size that is large enough to parse a maximum-length S-record. The maximum length of an S-record is 514 characters (2 for Record Type field + 2 for Byte Count field + 2*254 for Address and Data fields + 2 for Checksum field). Additional buffer space should be allocated as required for the line terminator(s), and a possible NUL string terminator (not part of an SREC file).

Data field - Though older documentation recommends a maximum of 32 bytes of data (64 hex characters), it should be ignored for modern parsing functions.[1] 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 doesn't officially support comments. Unofficially, software that ignores all text lines that doesn't start with "S" and ignores all text after the checksum field could treat extra text as comments. The CCS PIC compiler supports placing a ";" comment line at the top or bottom of an Intel HEX file, and its manuals stats "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.[3]

Software - Some poorly designed software have limitations reading various types of SREC files, such as: (1) not able to handle S1/S2/S3 data records with more than 16 or 32 data bytes, (2) not able to handle every SREC record type, (3) not able to handle missing SREC record types.[4]

Examples[edit]

Color legend

  Record type   Byte count   Address   Data   Checksum

Checksum calculation[edit]

The following example record:

S1137AF00A0A0D0000000000000000000000000061 

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[edit]

S00F000068656C6C6F202020202000003C
S11F00007C0802A6900100049421FFF07C6C1B787C8C23783C6000003863000026
S11F001C4BFFFFE5398000007D83637880010014382100107C0803A64E800020E9
S111003848656C6C6F20776F726C642E0A0042
S5030003F9
S9030000FC 

See also[edit]

References[edit]

Further reading[edit]

External links[edit]

Software
  • SRecord is a collection of tools for manipulating SREC format files.
  • BIN2MOT, BINARY to Motorola S-Record file converter utility.