1SREC(5) SREC(5)
2
6 srec - Motorola S-record record and file format
7
9 Motorola S-records are a form of simple ASCII encoding for binary data.
10 This format is commonly used for firmware uploads to GPSes, industrial
11 robots, and other kinds of microcontroller-driven hardware. It has sev‐
12 eral convenient properties, including inspectability, easy editing with
13 any text editor, and checksumming for verification of transmission
14 across noisy serial lines.
15 An S-record file consists of a sequence of specially formatted ASCII
18 character strings. An S-record will be less than or equal to 78 bytes
19 in length.
20 The order of S-records within a file is of no significance and no par‐
23 ticular order may be assumed.
24 The general format of an S-record follows:
27 +-------------------//------------------//-----------------------+
30 | type | count | address | data | checksum
31 |
32 +-------------------//------------------//-----------------------+
33 type A char[2] field. These characters describe the type of record
36 (S0, S1, S2, S3, S5, S7, S8, or S9).
37 count A char[2] field. These characters when paired and interpreted as
40 a hexadecimal value, display the count of remaining character
41 pairs in the record.
42 address
45 A char[4,6, or 8] field. These characters grouped and inter‐
46 preted as a hexadecimal value, display the address at which the
47 data field is to be loaded into memory. The length of the field
48 depends on the number of bytes necessary to hold the address. A
49 2-byte address uses 4 characters, a 3-byte address uses 6 char‐
50 acters, and a 4-byte address uses 8 characters.
51 data A char [0-64] field. These characters when paired and inter‐
54 preted as hexadecimal values represent the memory loadable data
55 or descriptive information.
56 checksum
59 A char[2] field. These characters when paired and interpreted as
60 a hexadecimal value display the least significant byte of the
61 ones complement of the sum of the byte values represented by the
62 pairs of characters making up the count, the address, and the
63 data fields.
64 Each record is terminated with a line feed. If any additional or dif‐
67 ferent record terminator(s) or delay characters are needed during
68 transmission to the target system it is the responsibility of the
69 transmitting program to provide them.
70 There are 9 record types, as follows:
73 S0 The type of record is 'S0' (0x5330). The address field is unused
76 and will be filled with zeros (0x0000). The header information
77 within the data field is divided into the following subfields.
78 1. mname is char[20] and is the module name.
82 2. ver is char[2] and is the version number.
84 3. rev is char[2] and is the revision number.
86 4. description is char[0-36] and is a text comment.
88 Each of the subfields is composed of ASCII bytes whose associ‐
90 ated characters, when paired, represent one byte hexadecimal
91 values in the case of the version and revision numbers, or rep‐
92 resent the hexadecimal values of the ASCII characters comprising
93 the module name and description.
94 S1 The type of record field is 'S1' (0x5331). The address field is
97 interpreted as a 2-byte address. The data field is composed of
98 memory loadable data.
99 S2 The type of record field is 'S2' (0x5332). The address field is
102 interpreted as a 3-byte address. The data field is composed of
103 memory loadable data.
104 S3 The type of record field is 'S3' (0x5333). The address field is
107 interpreted as a 4-byte address. The data field is composed of
108 memory loadable data.
109 S5 The type of record field is 'S5' (0x5335). The address field is
112 interpreted as a 2-byte value and contains the count of S1, S2,
113 and S3 records previously transmitted. There is no data field.
114 S7 The type of record field is 'S7' (0x5337). The address field
117 contains the starting execution address and is interpreted as a
118 4-byte address. There is no data field.
119 S8 The type of record field is 'S8' (0x5338). The address field
122 contains the starting execution address and is interpreted as a
123 3-byte address. There is no data field.
124 S9 The type of record field is 'S9' (0x5339). The address field
127 contains the starting execution address and is interpreted as a
128 2-byte address. There is no data field.
129
132 Shown below is a typical S-record format file.
133 S00600004844521B
136 S1130000285F245F2212226A000424290008237C2A
137 S11300100002000800082629001853812341001813
138 S113002041E900084E42234300182342000824A952
139 S107003000144ED492
140 S5030004F8
141 S9030000FC
142 The file consists of one S0 record, four S1 records, one S5 record and
146 an S9 record.
147 The S0 record is comprised as follows:
150 · S0 S-record type S0, indicating it is a header record.
153 · 06 Hexadecimal 06 (decimal 6), indicating that six character pairs
155 (or ASCII bytes) follow.
156 · 00 00 Four character 2-byte address field, zeroes in this example.
158 · 48 44 52 ASCII H, D, and R - "HDR".
160 · 1B The checksum.
162 The first S1 record is comprised as follows:
164 · S1 S-record type S1, indicating it is a data record to be loaded at
167 a 2-byte address.
168 · 13 Hexadecimal 13 (decimal 19), indicating that nineteen character
170 pairs, representing a 2 byte address, 16 bytes of binary data, and a
171 1 byte checksum, follow.
172 · 00 00 Four character 2-byte address field; hexidecimal address
174 0x0000, where the data which follows is to be loaded.
175 · 28 5F 24 5F 22 12 22 6A 00 04 24 29 00 08 23 7C Sixteen character
177 pairs representing the actual binary data.
178 · 2A The checksum.
180 The second and third S1 records each contain 0x13 (19) character pairs
182 and are ended with checksums of 13 and 52, respectively. The fourth S1
183 record contains 07 character pairs and has a checksum of 92.
184 The S5 record is comprised as follows:
187 · S5 S-record type S5, indicating it is a count record indicating the
190 number of S1 records
191 · 03 Hexadecimal 03 (decimal 3), indicating that three character pairs
193 follow.
194 · 00 04 Hexadecimal 0004 (decimal 4), indicating that there are four
196 data records previous to this record.
197 · F8 The checksum.
199 The S9 record is comprised as follows:
201 · S9 S-record type S9, indicating it is a termination record.
204 · 03 Hexadecimal 03 (decimal 3), indicating that three character pairs
206 follow.
207 · 00 00 The address field, hexadecimal 0 (decimal 0) indicating the
209 starting execution address.
210 · FC The checksum.
212
214 · There isn't any evidence that Motorola ever made use of the header
215 information within the data field of the S0 record, as described
216 above. This may have been used by some third party vendors.
217 · The Unix manual page on S-records is the only place that a 78-byte
219 limit on total record length or 64-byte limit on data length is doc‐
220 umented. These values shouldn't be trusted for the general case.
221 · The count field can have values in the range of 0x3 (2 bytes of
223 address + 1 byte checksum = 3, a not very useful record) to 0xff;
224 this is the count of remaining character pairs, including checksum.
225 · If you write code to convert S-Records, you should always assume
227 that a record can be as long as 514 (decimal) characters in length
228 (255 * 2 = 510, plus 4 characters for the type and count fields),
229 plus any terminating character(s). That is, in establishing an input
230 buffer in C, you would declare it to be an array of 515 chars, thus
231 leaving room for the terminating null character.
232
234 gpsd(8), gps(1), libgps(3), libgpsd(3), gpsfake(1). gpsprof(1).
235
238 From an anonymous web page, itself claiming to have been derived from
239 an old Unix manual page. Now maintained by the the GPSD project. There
240 is a project page for gpsd here: http://gpsd.berlios.de/.
241 SREC(5)