SREC (file format)

Motorola S-record is a file format, created by Motorola, that

conveys binary information as hex values in ASCII text form. S-record
This file format may also be known as SRECORD, SREC, S19,
S28, S37. It is commonly used for programming flash memory in
microcontrollers, EPROMs, EEPROMs, 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 non-volatile memory, or is transferred to
the target system for loading and execution.
A quick reference chart for the
Motorola SREC format. (Note that in
the record example image the word
Contents "bytes" is alternatively used to
specify characters.)
Overview
History Filename .s19, .s28,
extension .s37, .s, .s1,
Other hex formats
.s2, .s3, .sx,
Format .srec, .exo,[1]
Record structure .mot, .mxt
Text line terminators Developed by Motorola
Record types
Record order
Limitations
Examples
Checksum calculation
16-bit memory address
See also
References
Further reading
External links

Overview

History

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. TekHex is another hex format that can include a symbol table for debugging.

Format

Record structure

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 start - each record begins with an uppercase letter "S" character (ASCII 0x53) which
stands for "Start-of-Record".[2]
2. Record type - single numeric digit "0" to "9", defining the type of record.
3. 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).
4. Address - four / six / eight hex digits as determined by the record type. The address bytes are
arranged in big-endian format.
5. 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.
6. 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 character (line feed, 0x0A as
ASCII character value) character to terminate lines, whereas Windows programs use a CR character
(carriage return, 0x0D as ASCII character value) followed by a LF character.

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.

Record Record Address Data Record

field purpose field field description
This record contains vendor specific ASCII text comment
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
16-bit data can be anything including a mixture of the following
S0 Header information: file/module name, version/revision number, date/time,
"0000"
product name, vendor name, memory designator on PCB, copyright
notice, sign on.[3] It is common to see: 48 44 52 which is the ASCII
H, D, and R - "HDR".[4]

This record contains data that starts at the 16-bit address field.[5][3]
16-bit This record is typically used for 8-bit microcontrollers, such as
S1 Data AVR, PIC, 8051, 68xx, 6502, 80xx, Z80. The number of bytes of
Address
data contained in this record is "Byte Count Field" minus 3 (that is,
2 bytes for "16-bit Address Field" and 1 byte for "Checksum Field").

This record contains data that starts at a 24-bit address.[5] The

24-bit number of bytes of data contained in this record is "Byte Count
S2 Data
Address Field" minus 4 (that is, 3 bytes for "24-bit Address Field" and 1 byte
for "Checksum Field").

This record contains data that starts at a 32-bit address.[5] This

32-bit record is typically used for 32-bit microcontrollers, such as ARM
S3 Data and 680x0. The number of bytes of data contained in this record is
Address
"Byte Count Field" minus 5 (that is, 4 bytes for "32-bit Address
Field" and 1 byte for "Checksum Field").
S4 Reserved N/A N/A This record is reserved.

16-bit This optional record contains a 16-bit count of S1/S2/S3 records.[5]

S5 Count This record is used if the record count is less than or equal to
Count
65,535 (0xFFFF), otherwise S6 record would be used.
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
24-bit
S6 Count 16,777,215 (0xFFFFFF). If less than 65,536 (0x10000), then S5
Count
record would be used. NOTE: This newer record is the most recent
change (it may not be official).[5]
This record contains the starting execution location at a 32-bit
Start
32-bit address.[5][6] This is used to terminate a series of S3 records. If a
S7 Address SREC file is only used to program a memory device and the
Address
(Termination) execution location is ignored, then an address of zero could be
used.
This record contains the starting execution location at a 24-bit
Start
24-bit address.[5][6] This is used to terminate a series of S2 records. If a
S8 Address SREC file is only used to program a memory device and the
Address
(Termination) execution location is ignored, then an address of zero could be
used.
This record contains the starting execution location at a 16-bit
Start
16-bit address.[5][6] This is used to terminate a series of S1 records.[3] If a
S9 Address SREC file is only used to program a memory device and the
Address
(Termination) execution location is ignored, then an address of zero could be
used.

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",[5] 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.

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

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).[5] 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".[5] If that limitation is ignored, the maximum length of an
S-record is 514 characters, thus assuming a Byte Count of 0xFF (255), it would be 2 for Record Type field
+ 2 for Byte Count field + (2 * 255) for Address / Data / 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."[7]

Data field - Some documentation recommends a maximum of 32 bytes of data (64 hex characters) in this
field.[5] 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.[8]

Examples
Color legend

Record type Byte count Address Data Checksum

Checksum calculation

The following example record:

S1137AF00A0A0D0000000000000000000000000061

is decoded to show how the checksum value is calculated. The following example uses a dollar sign ($) to
indicate a hexadecimal value (a Motorola convention):

1. Add: Add each byte $13 + $7A + $F0 + $0A + $0A + $0D + $00 + ... + $00 = $019E.
2. Mask: Discard the most significant byte ($01) of the sum and retain the least significant byte
(LSB), which is $9E.
3. Complement: Compute the ones' complement of the LSB, which is $61. Typically this is
accomplished on the Motorola 6800 microprocessor by exclusive-ORing the accumulator
with $FF.

16-bit memory address

S00F000068656C6C6F202020202000003C
S11F00007C0802A6900100049421FFF07C6C1B787C8C23783C6000003863000026
S11F001C4BFFFFE5398000007D83637880010014382100107C0803A64E800020E9
S111003848656C6C6F20776F726C642E0A0042
S5030003F9
S9030000FC

See also
Binary-to-text encoding, a survey and comparison of encoding algorithms
Intel hex format
MOS Technology file format
Tektronix hex format

References
1. "AR#476 PROMGen - Description of PROM/EEPROM file formats: MCS, EXO, HEX, and
others" (https://www.xilinx.com/support/answers/476.html). Xilinx. 2010-03-08. Motorola
 EXORmacs - File Format Code 87. Archived (https://web.archive.org/web/20200303085851/
https://www.xilinx.com/support/answers/476.html) from the original on 2020-03-03. Retrieved
2020-03-03.
2. Wiles, Mike; Felix, Andre (2000-10-21) [1975]. Holley, Michael (ed.). MCM6830L7 MIKBUG /
MINIBUG ROM (https://web.archive.org/web/20190616115550/http://www.swtpc.com/mholle
y/MP_A/MikbugEn100.pdf) (PDF) (Engineering note). Motorola Semiconductor Products,
Inc. Note 100. Archived from the original (http://www.swtpc.com/mholley/MP_A/MikbugEn10
0.pdf) (PDF) on 2019-06-16. Retrieved 2019-06-16. (23 pages)
3. Hennig-Roleff, Werner (1993-02-01) [1988]. "HEX.DOC: Motorola - HEX Format" (http://spot.
fho-emden.de/ftp/micro/sim51_04.zip). SIM51. 1.04 (in German). Archived (https://web.archiv
e.org/web/20170811161238/http://spot.fho-emden.de/ftp/micro/sim51_04.zip) from the
original on 2017-08-11. Retrieved 2021-12-08. (NB. This is an older version of SIM51, the
software and documentation was maintained up to 1996.)
4. Tareski, Val. "Motorola S-record description"
(http://www.amelek.gda.pl/avr/uisp/srecord.htm). www.amelek.gda.pl. Retrieved 2018-06-26.
5. "Motorola S-records from Unix man pages" (http://www.amelek.gda.pl/avr/uisp/srecord.htm).
Retrieved 2014-06-30.
6. "Appendix C". M68000 Family Programmer's Reference Manual (http://www.freescale.com/fi
les/archives/doc/ref_manual/M68000PRM.pdf) (PDF). Revision 1. Motorola (Freescale).
1992. pp. C-1–C-5. ISBN 978-0-13723289-5.
7. "srec_examples" (http://srecord.sourceforge.net/man/man1/srec_examples.html).
sourceforge.net.
8. CCS Compiler Reference Manual PCB/PCM/PCH (http://www.ccsinfo.com/downloads/ccs_
c_manual.pdf) (PDF), Custom Computer Services, Inc., May 2014, p. 107, retrieved
2015-02-08

Further reading
"2.8. Microprocessor Formats 2.8.1. Input Requirements: Motorola Exorciser Format. Select
Code 82". Operator Guide To Serial I/O Capabilities of Data I/O Programmers - Translation
Format Package (http://bitsavers.trailing-edge.com/test_equipment/dataIO/055-1901_Syste
m19_transPkg.pdf) (PDF). Revision C. Data I/O Corporation. October 1980. p. 2-9. 055-
1901. Archived (https://web.archive.org/web/20200301134810/http://bitsavers.trailing-edge.c
om/test_equipment/dataIO/055-1901_System19_transPkg.pdf) (PDF) from the original on
2020-03-01. Retrieved 2020-03-01.
M1468705EVM Evaluation Module User's Manual (https://archive.org/details/bitsavers_moto
rola68ionModuleUsersManualDec83_3216374) (1 ed.). Motorola Inc. December 1983.
M1468705EVM/Dl. Retrieved 2020-03-01. [1] (https://archive.org/stream/bitsavers_motorola
68ionModuleUsersManualDec83_3216374/M146805EVM_Evaluation_Module_Users_Man
ual_Dec83_djvu.txt)[2] (https://archive.org/download/bitsavers_motorola68ionModuleUsers
ManualDec83_3216374/M146805EVM_Evaluation_Module_Users_Manual_Dec83.pdf)
Translation File Formats (ftp://ftp.dataio.com/main/Manuals/UniFam/Translation%252520For
mats.pdf+&cd=21&hl=de&ct=clnk&gl=de&client=firefox-b-d). Data I/O Corporation. 1987-09-
03. Archived (https://web.archive.org/web/20200301114550/http://webcache.googleusercont
ent.com/search?q=cache:wC7iuE425G4J:ftp://ftp.dataio.com/main/Manuals/UniFam/Transla
tion%252520Formats.pdf+&cd=21&hl=de&ct=clnk&gl=de&client=firefox-b-d) from the
original on 2020-03-01. Retrieved 2020-03-01. [3] (https://web.archive.org/web/2021072819
0952/ftp://ftp.dataio.com/main/Manuals/UniFam/Translation%20Formats.pdf) (56 pages)
Feichtinger, Herwig (1987). "1.8.5. Lochstreifen-Datenformate: Das Motorola-S-Format"
[1.8.5. Paper tape data formats]. Arbeitsbuch Mikrocomputer [Microcomputer work book] (in
German) (2 ed.). Munich, Germany: Franzis-Verlag GmbH. pp. 240–243 [242]. ISBN 3-7723-
8022-0.
 "Appendix A. S Record Information". M68HC05EVM Evaluation Module User's Manual (htt
p://www.68bits.com/M68HC05EVM.pdf) (PDF) (4 ed.). Motorola. 1990. p. A-1. "[…] For
compatibility with teletypewriters, some programs may limit the number of [data] bytes to as
few as 28 (56 printable characters in the S-record). […]"
"How Do I Interpret Motorola S & Intel HEX Formatted Data? Motorola S-Records" (https://w
ww.keysight.com/main/editorial.jspx?ckey=25084%3Aatg%3Afaq&id=25084%3Aatg%3Afaq
&nid=-35181.0.00&lc=ger&cc=DE). Home > Hardware > … > In-circuit Test Systems >
Automated Test Equipment [Discontinued] > Details. Keysight Technologies. Archived (http
s://web.archive.org/web/20200301171624/https://www.keysight.com/main/editorial.jspx?cke
y=25084%3Aatg%3Afaq&id=25084%3Aatg%3Afaq&nid=-35181.0.00&lc=ger&cc=DE) from
the original on 2020-03-01. Retrieved 2020-03-01.
Beard, Brian (2016) [2007]. "Motorola S-record Format" (http://www.lucidtechnologies.info/m
oto.htm). Lucid Technologies. Archived (https://web.archive.org/web/20200228153613/http://
www.lucidtechnologies.info/moto.htm) from the original on 2020-02-28. Retrieved
2020-02-28.
Strombergson, Joachim; Walleij, Linus; Faltstrom, Patrik (October 2005). "The S Hexdump
Format" (https://tools.ietf.org/html/rfc4194). IETF. RFC 4194 (https://datatracker.ietf.org/doc/ht
ml/rfc4194). Archived (https://web.archive.org/web/20200301225557/https://tools.ietf.org/htm
l/rfc4194) from the original on 2020-03-01. Retrieved 2020-03-01.

External links
SRecord (http://srecord.sourceforge.net/) is a collection of tools for manipulating SREC
format files.
BIN2MOT (http://www.keil.com/download/docs/4.asp), BINARY to Motorola S-Record file
converter utility.
SRecordizer (https://github.com/BigWinston/SRecordizer/wiki) is a tool for viewing, editing,
and error checking S19 format files.
bincopy (https://pypi.python.org/pypi/bincopy) is a Python package for manipulating SREC
format files.
kk_srec (https://github.com/arkku/srec) is a C library and program for reading the SREC
format.

Retrieved from "https://en.wikipedia.org/w/index.php?title=SREC_(file_format)&oldid=1062984946"

This page was last edited on 31 December 2021, at 15:41 (UTC).

Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using
this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia
Foundation, Inc., a non-profit organization.