1SREC(5) GPSD Documentation 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
12 several convenient properties, including inspectability, easy editing
13 with 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
17 character strings. An S-record will be less than or equal to 78 bytes
18 in length.
19 The order of S-records within a file is of no significance and no
21 particular order may be assumed.
22 The general format of an S-record follows:
24 +-------------------//------------------//-----------------------+
26 | type | count | address | data | checksum |
27 +-------------------//------------------//-----------------------+
28 type
30 A char[2] field. These characters describe the type of record (S0,
31 S1, S2, S3, S5, S7, S8, or S9).
32 count
34 A char[2] field. These characters when paired and interpreted as a
35 big-endian hexadecimal integer, display the count of remaining
36 character pairs in the record.
37 address
39 A char[4,6, or 8] field. These characters grouped and interpreted
40 as a big-endian hexadecimal integer, display the address at which
41 the data field is to be loaded into memory. The length of the field
42 depends on the number of bytes necessary to hold the address. A
43 2-byte address uses 4 characters, a 3-byte address uses 6
44 characters, and a 4-byte address uses 8 characters.
45 data
47 A char [0-64] field. These characters when paired and interpreted
48 as hexadecimal values represent the memory loadable data or
49 descriptive information.
50 checksum
52 A char[2] field. These characters when paired and interpreted as a
53 big-endian hexadecimal integer display the least significant byte
54 of the ones complement of the sum of the byte values represented by
55 the pairs of characters making up the count, the address, and the
56 data fields.
57 Each record is terminated with a line feed. If any additional or
59 different record terminator(s) or delay characters are needed during
60 transmission to the target system it is the responsibility of the
61 transmitting program to provide them.
62 There are 9 record types, as follows:
64 S0
66 The type of record is 'S0' (0x5330). The address field is unused
67 and will be filled with zeros (0x0000). The header information
68 within the data field is divided into the following subfields.
69 1. mname is char[20] and is the module name.
71 2. ver is char[2] and is the version number.
73 3. rev is char[2] and is the revision number.
75 4. description is char[0-36] and is a text comment.
77 Each of the subfields is composed of ASCII bytes whose associated
79 characters, when paired, represent one byte hexadecimal values in
80 the case of the version and revision numbers, or represent the
81 hexadecimal values of the ASCII characters comprising the module
82 name and description.
83 S1
85 The type of record field is 'S1' (0x5331). The address field is
86 interpreted as a 2-byte big-endian address. The data field is
87 composed of memory loadable data.
88 S2
90 The type of record field is 'S2' (0x5332). The address field is
91 interpreted as a 3-byte big-endian address. The data field is
92 composed of memory loadable data.
93 S3
95 The type of record field is 'S3' (0x5333). The address field is
96 interpreted as a 4-byte big-endian address. The data field is
97 composed of memory loadable data.
98 S5
100 The type of record field is 'S5' (0x5335). The address field is
101 interpreted as a 2-byte big-endian value and contains the count of
102 S1, S2, and S3 records previously transmitted. There is no data
103 field.
104 S7
106 The type of record field is 'S7' (0x5337). The address field
107 contains the starting execution address and is interpreted as a
108 4-byte big-endian address. There is no data field.
109 S8
111 The type of record field is 'S8' (0x5338). The address field
112 contains the starting execution address and is interpreted as a
113 3-byte big-endian address. There is no data field.
114 S9
116 The type of record field is 'S9' (0x5339). The address field
117 contains the starting execution address and is interpreted as a
118 2-byte big-endian address. There is no data field.
119
121 Shown below is a typical S-record format file.
122 S00600004844521B
124 S1130000285F245F2212226A000424290008237C2A
125 S11300100002000800082629001853812341001813
126 S113002041E900084E42234300182342000824A952
127 S107003000144ED492
128 S5030004F8
129 S9030000FC
130 The file consists of one S0 record, four S1 records, one S5 record and
132 an S9 record.
133 The S0 record is comprised as follows:
135 · S0 S-record type S0, indicating it is a header record.
137 · 06 Hexadecimal 06 (decimal 6), indicating that six character pairs
139 (or ASCII bytes) follow.
140 · 00 00 Four character 2-byte address field, zeroes in this example.
142 · 48 44 52 ASCII H, D, and R - "HDR".
144 · 1B The checksum.
146 The first S1 record is comprised as follows:
148 · S1 S-record type S1, indicating it is a data record to be loaded at
150 a 2-byte address.
151 · 13 Hexadecimal 13 (decimal 19), indicating that nineteen character
153 pairs, representing a 2 byte address, 16 bytes of binary data, and
154 a 1 byte checksum, follow.
155 · 00 00 Four character 2-byte address field; hexidecimal address
157 0x0000, where the data which follows is to be loaded.
158 · 28 5F 24 5F 22 12 22 6A 00 04 24 29 00 08 23 7C Sixteen character
160 pairs representing the actual binary data.
161 · 2A The checksum.
163 The second and third S1 records each contain 0x13 (19) character pairs
165 and are ended with checksums of 13 and 52, respectively. The fourth S1
166 record contains 07 character pairs and has a checksum of 92.
167 The S5 record is comprised as follows:
169 · S5 S-record type S5, indicating it is a count record indicating the
171 number of S1 records
172 · 03 Hexadecimal 03 (decimal 3), indicating that three character
174 pairs follow.
175 · 00 04 Hexadecimal 0004 (decimal 4), indicating that there are four
177 data records previous to this record.
178 · F8 The checksum.
180 The S9 record is comprised as follows:
182 · S9 S-record type S9, indicating it is a termination record.
184 · 03 Hexadecimal 03 (decimal 3), indicating that three character
186 pairs follow.
187 · 00 00 The address field, hexadecimal 0 (decimal 0) indicating the
189 starting execution address.
190 · FC The checksum.
192
194 · There isn't any evidence that Motorola ever made use of the header
195 information within the data field of the S0 record, as described
196 above. This may have been used by some third party vendors.
197 · The Unix manual page on S-records is the only place that a 78-byte
199 limit on total record length or 64-byte limit on data length is
200 documented. These values shouldn't be trusted for the general case.
201 · The count field can have values in the range of 0x3 (2 bytes of
203 address + 1 byte checksum = 3, a not very useful record) to 0xff;
204 this is the count of remaining character pairs, including checksum.
205 · If you write code to convert S-Records, you should always assume
207 that a record can be as long as 514 (decimal) characters in length
208 (255 * 2 = 510, plus 4 characters for the type and count fields),
209 plus any terminating character(s). That is, in establishing an
210 input buffer in C, you would declare it to be an array of 515
211 chars, thus leaving room for the terminating null character.
212
214 gpsd(8), gps(1), libgps(3), libgpsd(3), gpsfake(1). gpsprof(1).
215
217 From an anonymous web page, itself claiming to have been derived from
218 an old Unix manual page. Now maintained by the the GPSD project, which
219 added endianness clarifications. There is a project page for gpsd
220 here[1].
221
223 1. here
224 http://gpsd.berlios.de/
225The GPSD Project 15 Jul 2005 SREC(5)