Login
Login

SREC (file format)

{{Short description|File format developed by Motorola}}

{{Distinguish|Motorola hexadecimal notation}}

{{Use dmy dates|date=March 2020|cs1-dates=y}}

{{Use list-defined references|date=December 2021}}

{{Infobox file format

|name = S-record

|icon =

|screenshot = File:Motorola SREC Chart.png

|caption = A quick reference chart for the Motorola SREC format. (Note that in the record example image the word "bytes" is alternatively used to specify characters.)

|extension = .s19, .s28, .s37, .s, .s1, .s2, .s3, .sx, .srec, .exo, .mot, .mxt

|mime =

|developer = Motorola

|type =

|url =

}}

Motorola S-record is a file format, created by Motorola in the mid-1970s, that conveys binary information as hex values in ASCII text form. 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 write the machine code into non-volatile memory, or is transferred to the target system for loading and execution.

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.  The basic S-record format was subsequently extended to handle 24- and 32-bit addresses for compatibility with the MC68000 series of microprocessors.

=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=

class="wikitable" style="text-align:center"
style='background: #FFCCCC' | Sstyle='background: #FFCCCC' | Typestyle='background: #CCFFCC' | Byte Countstyle='background: #CCCCFF' | Addressstyle='background: #CCFFFF' | Datastyle='background: #CCCCCC' | 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. Record type - single numeric digit "0" to "9" character (ASCII 0x30 to 0x39), defining the type of record. See table below.
  3. Byte count - two hex digits ("00" to "FF"), 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 (2 for 16-bit address field plus 1 checksum byte), and a maximum value of 255 (0xFF). "00" / "01" / "02" are illegal values.
  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. In the C programming language, the sum is converted into the checksum by: 0xFF - (sum & 0xFF)

=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 the 10 possible S-record types.

class="wikitable"
Record
field

! Record
purpose

! Address
field

! Data
field

! Record
description

align="center" | S0

| Header

| {{n/a}}

| {{Ya}}

| The data field in this record type may be empty, or may contain the hex equivalent of application-specific ASCII information, often in the form of a null-terminated string.  In lieu of more specific information, it is common to see 48, 44, 52, which is the ASCII representation of the letters "HDR".  The address field will always contain the hex representation of $0000 ($ indicates a hexadecimal number in Motorola 6800 assembly language).

align="center" | S1

| Data

| 16-bit
address

| {{Ya}}

| The data field in this record type contains data that is loaded to the 16-bit address in the address field. The number of bytes of data contained in this record is "Byte Count Field" minus 3 (2 bytes for "16-bit Address Field" plus 1 byte for "Checksum Field"). This record type is typically used with eight-bit processors, such as the 6502 and 6800 families, the 8051, the Z80, the AVR and PIC.

align="center" | S2

| Data

| 24-bit
address

| {{Ya}}

| The data field in this record type contains data that is loaded to the 24-bit address in the address field. The number of bytes of data contained in this record is "Byte Count Field" minus 4 (3 bytes for "24-bit Address Field" plus 1 byte for "Checksum Field").  The S2 record type was added by Motorola to support the MC68000 microprocessor, which has a 24-bit address bus.  This record type is also usable with the Western Design Center 65C816, which emits 24-bit addresses.

align="center" | S3

| Data

| 32-bit
address

| {{Ya}}

| The data field in this record type contains data that is loaded to the 32-bit address in the address field. The number of bytes of data contained in this record is "Byte Count Field" minus 5 (4 bytes for "32-bit Address Field" plus 1 byte for "Checksum Field"). The S3 record type was added to support the 68012 and later 68000-series microprocessors that are equipped with a 32-bit data bus.  This record type is also usable with non-Motorola 32-bit processors, such as the ARM architecture family and the RISC-V.

align="center" | S4

| Undefined

| {{n/a}}

| {{n/a}}

| This record type is not defined by the official S-record standard.

align="center" | S5

| Count

| 16-bit
count

| {{Na}}

| This optional record type contains a 16-bit count of S1/S2/S3 records that have been transmitted.  The data field is not used.

align="center" | S6

| Non-standard

| 24-bit
count

| {{Na}}

| This record type is not defined by the official S-record standard.  However, some applications treat this record as an optional 24-bit count of S1/S2/S3 records that have been transmitted.  In such an application, the data field is not used.

align="center" | S7

| Start address
(termination)

| 32-bit
address

| {{Na}}

| This record type contains an optional 32-bit address that is the entry point for program execution.  An address of $00000000 is used if no specific address is required, such as when S-records are used to burn EPROMs and the like.  This record type is used to terminate a series of S3 records. The data field is not used.

align="center" | S8

| Start address
(termination)

| 24-bit
address

| {{Na}}

| This record type contains an optional 24-bit address that is the entry point for program execution. An address of $000000 is used if no specific address is required.  This record type is used to terminate a series of S2 records. The data field is not used.

align="center" | S9

| Start address
(termination)

| 16-bit
address

| {{Na}}

| This record type contains an optional 16-bit address that is the entry point for program execution. An address of $0000 is used if no specific address is required. This record type is used to terminate a series of S1 records. The data field is not 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", 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==

A manual page from historic Unix O/S 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), and fits 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 the 78 byte historical limit is ignored, the maximum length of an S-record would be 514 characters. 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 to hold up to two control characters (carriage return and/or line feed), and/or a NUL (0x00) string terminator for C/C++ programming languages. 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==

The minimum amount of data for S0/S1/S2/S3 records is zero.

Some historical documentation recommends a maximum of 32 bytes of data (64 hex characters) in this field (maybe because 32 is the largest power of 2 of data that would fit on an 80 column wide teleprinter / computer terminal / punched card).

If the 32 byte historical limit is ignored, then the maximum amount of data varies depending on the size of the address field (4 / 6 / 8). The maximum number of bytes of data is calculated by 255 (maximum for Byte Count field) minus (1 byte for Checksum field) minus (number of bytes in the Address field), thus the maximum amount of data for each record type is: 252 data bytes (504 hex characters) for S0 & S1 records, 251 data bytes (502 hex characters) for S2 records, 250 data bytes (500 hex characters) for S3 records.

==Comments==

Other than ASCII-to-hex converted comments in S0 header records, the SREC file format doesn't officially support human-readable ASCII comments, though some software ignores all lines that don't start with "S" and/or ignores all text after the Checksum field (thus trailing 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

; Color legend

{{legend inline| #FFCCCC |Record type}}

{{legend inline| #CCFFCC |Byte count}}

{{legend inline| #CCCCFF |Address}}

{{legend inline| #CCFFFF |Data}}

{{legend inline| #CCCCCC |Checksum}}

=Checksum calculation=

The following example record:

{{SREC HEX|1|13|7AF0|0A0A0D00000000000000000000000000|61}}

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

  1. Add: Add each byte {{code|1=$13 + $7A + $F0 + $0A + $0A + $0D + $00 + ... + $00 = $019E}} sum.
  2. Mask: Discard the most significant byte ({{code|$01}}) of the sum and retain the least significant byte (LSB), which is {{code|$9E}}.
  3. Complement: Compute the ones' complement of the LSB, which is {{code|$61}}.

In the C programming language, the sum is converted into the checksum by: {{code|0xFF - (sum & 0xFF)|c}}

=16-bit memory address=

{{SREC HEX|0|0F|0000|68656C6C6F20202020200000|3C}}

{{SREC HEX|1|1F|0000|7C0802A6900100049421FFF07C6C1B787C8C23783C60000038630000|26}}

{{SREC HEX|1|1F|001C|4BFFFFE5398000007D83637880010014382100107C0803A64E800020|E9}}

{{SREC HEX|1|11|0038|48656C6C6F20776F726C642E0A00|42}}

{{SREC HEX|5|03|0003||F9}}

{{SREC HEX|9|03|0000||FC}}

See also

References

{{Reflist|refs=

{{cite web |title=Motorola S-records (UNIX man page and comments) |url=http://www.amelek.gda.pl/avr/uisp/srecord.htm |website=Uisp AVR In-System Programmer |archive-url=https://web.archive.org/web/20020703084158/http://www.amelek.gda.pl/avr/uisp/srecord.htm |archive-date=July 3, 2002 |url-status=dead}}

{{cite book |title=M68000 Family Programmer's Reference Manual |version=Revision 1 |publisher=Motorola |date=1992 |pages=C-1–C-5 |chapter=Appendix C |isbn=978-0-13723289-5 |url=https://archive.org/details/M68000PRM/page/n639/mode/2up}}

{{cite web |title=srec_examples and srec_cat |url=https://srecord.sourceforge.net/man/man1/srec_examples.html |website=SourceForge |archive-url=https://web.archive.org/web/20130127033937/https://srecord.sourceforge.net/man/man1/srec_examples.html |archive-date=January 27, 2013 |url-status=dead}}

{{citation |title=CCS Compiler Reference Manual PCB/PCM/PCH |publisher=Custom Computer Services, Inc. |date=May 2014 |page=142 |url=http://www.ccsinfo.com/downloads/ccs_c_manual.pdf |access-date=2015-02-08}}

{{cite web |title=AR#476 PROMGen - Description of PROM/EEPROM file formats: MCS, EXO, HEX, and others |at=Motorola EXORmacs - File Format Code 87 |date=2010-03-08 |publisher=Xilinx |url=https://www.xilinx.com/support/answers/476.html |access-date=2020-03-03 |archive-url=https://web.archive.org/web/20200303085851/https://www.xilinx.com/support/answers/476.html |archive-date=2020-03-03 |url-status=dead}}

{{cite web |title=HEX.DOC: Motorola - HEX Format |author-first=Werner |author-last=Hennig-Roleff |language=de |date=1993-02-01 |orig-date=1988 |version=1.04 |work=SIM51 |url=http://spot.fho-emden.de/ftp/micro/sim51_04.zip |access-date=2021-12-08 |url-status=live |archive-url=https://web.archive.org/web/20170811161238/http://spot.fho-emden.de/ftp/micro/sim51_04.zip |archive-date=2017-08-11}} (NB. This is an older version of SIM51, the software and documentation was maintained up to 1996.)

{{cite book |title=MCM6830L7 MIKBUG / MINIBUG ROM |author-first1=Mike |author-last1=Wiles |author-first2=Andre |author-last2=Felix |editor-first=Michael |editor-last=Holley |date=2000-10-21 |orig-date=1975 |type=Engineering note |id=Note 100 |publisher=Motorola Semiconductor Products, Inc. |url=http://www.swtpc.com/mholley/MP_A/MikbugEn100.pdf |access-date=2019-06-16 |archive-url=https://web.archive.org/web/20190616115550/http://www.swtpc.com/mholley/MP_A/MikbugEn100.pdf |archive-date=2019-06-16 |url-status=dead}} (23 pages)

}}

Further reading

  • {{cite book |title=Operator Guide To Serial I/O Capabilities of Data I/O Programmers - Translation Format Package |chapter=2.8. Microprocessor Formats 2.8.1. Input Requirements: Motorola Exorciser Format. Select Code 82 |id=055-1901 |version=Revision C |date=October 1980 |publisher=Data I/O Corporation |pages=2–9 |url=http://bitsavers.trailing-edge.com/test_equipment/dataIO/055-1901_System19_transPkg.pdf |access-date=2020-03-01 |url-status=live |archive-url=https://web.archive.org/web/20200301134810/http://bitsavers.trailing-edge.com/test_equipment/dataIO/055-1901_System19_transPkg.pdf |archive-date=2020-03-01}}
  • {{cite book |title=M1468705EVM Evaluation Module User's Manual |edition=1 |id=M1468705EVM/Dl |publisher=Motorola Inc. |date=December 1983 |url=https://archive.org/details/bitsavers_motorola68ionModuleUsersManualDec83_3216374 |access-date=2020-03-01}} [https://archive.org/stream/bitsavers_motorola68ionModuleUsersManualDec83_3216374/M146805EVM_Evaluation_Module_Users_Manual_Dec83_djvu.txt][https://archive.org/download/bitsavers_motorola68ionModuleUsersManualDec83_3216374/M146805EVM_Evaluation_Module_Users_Manual_Dec83.pdf]
  • {{cite book |title=Translation File Formats |date=1987-09-03 |publisher=Data I/O Corporation |url=ftp://ftp.dataio.com/main/Manuals/UniFam/Translation%252520Formats.pdf+&cd=21&hl=de&ct=clnk&gl=de&client=firefox-b-d |access-date=2020-03-01 |url-status=live |archive-url=https://web.archive.org/web/20200301114550/http://webcache.googleusercontent.com/search?q=cache:wC7iuE425G4J:ftp://ftp.dataio.com/main/Manuals/UniFam/Translation%252520Formats.pdf+&cd=21&hl=de&ct=clnk&gl=de&client=firefox-b-d |archive-date=2020-03-01}} [https://web.archive.org/web/20210728190952/ftp://ftp.dataio.com/main/Manuals/UniFam/Translation%20Formats.pdf] (56 pages)
  • {{cite book |author-first=Herwig |author-last=Feichtinger |title=Arbeitsbuch Mikrocomputer |trans-title=Microcomputer work book |chapter=1.8.5. Lochstreifen-Datenformate: Das Motorola-S-Format |trans-chapter=1.8.5. Paper tape data formats |language=de |location=Munich, Germany |publisher=Franzis-Verlag GmbH |isbn=3-7723-8022-0 |date=1987 |edition=2 |pages=240–243 [242]}}
  • {{cite book |title=M68HC05EVM Evaluation Module User's Manual |edition=4 |publisher=Motorola |date=1990 |chapter=Appendix A. S Record Information |page=A-1 |url=http://www.68bits.com/M68HC05EVM.pdf |quote=[…] 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). […]}}
  • {{cite web |title=How Do I Interpret Motorola S & Intel HEX Formatted Data? Motorola S-Records |work=Home > Hardware > … > In-circuit Test Systems > Automated Test Equipment [Discontinued] > Details |publisher=Keysight Technologies |url=https://www.keysight.com/main/editorial.jspx?ckey=25084%3Aatg%3Afaq&id=25084%3Aatg%3Afaq&nid=-35181.0.00&lc=ger&cc=DE |access-date=2020-03-01 |url-status=live |archive-url=https://web.archive.org/web/20200301171624/https://www.keysight.com/main/editorial.jspx?ckey=25084%3Aatg%3Afaq&id=25084%3Aatg%3Afaq&nid=-35181.0.00&lc=ger&cc=DE |archive-date=2020-03-01}}
  • {{cite web |title=Motorola S-record Format |author-first=Brian |author-last=Beard |date=2016 |orig-date=2007 |work=Lucid Technologies |url=http://www.lucidtechnologies.info/moto.htm |access-date=2020-02-28 |url-status=live |archive-url=https://web.archive.org/web/20200228153613/http://www.lucidtechnologies.info/moto.htm |archive-date=2020-02-28}}
  • {{cite web |title=The S Hexdump Format |author-first1=Joachim |author-last1=Strombergson |author-first2=Linus |author-last2=Walleij |author-first3=Patrik |author-last3=Faltstrom |date=October 2005 |id={{IETF-RFC|4194}} |publisher=IETF |url=https://tools.ietf.org/html/rfc4194 |access-date=2020-03-01 |url-status=live |archive-url=https://web.archive.org/web/20200301225557/https://tools.ietf.org/html/rfc4194 |archive-date=2020-03-01}}

External links

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

{{DEFAULTSORT:Srec (File Format)}}

Category:Binary-to-text encoding formats

Category:Embedded systems

Category:Computer file formats