1SREC(5) GPSD Documentation SREC(5)
2
3
4
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
16 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
20 The order of S-records within a file is of no significance and no
21 particular order may be assumed.
22
23 The general format of an S-record follows:
24
25 +-------------------//------------------//-----------------------+
26 | type | count | address | data | checksum |
27 +-------------------//------------------//-----------------------+
28
29 type
30 A char[2] field. These characters describe the type of record (S0,
31 S1, S2, S3, S5, S7, S8, or S9).
32
33 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
38 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
46 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
51 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
58 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
63 There are 9 record types, as follows:
64
65 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
70 1. mname is char[20] and is the module name.
71
72 2. ver is char[2] and is the version number.
73
74 3. rev is char[2] and is the revision number.
75
76 4. description is char[0-36] and is a text comment.
77
78 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
84 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
89 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
94 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
99 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
105 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
110 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
115 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
123 S00600004844521B
124 S1130000285F245F2212226A000424290008237C2A
125 S11300100002000800082629001853812341001813
126 S113002041E900084E42234300182342000824A952
127 S107003000144ED492
128 S5030004F8
129 S9030000FC
130
131 The file consists of one S0 record, four S1 records, one S5 record and
132 an S9 record.
133
134 The S0 record is comprised as follows:
135
136 · S0 S-record type S0, indicating it is a header record.
137
138 · 06 Hexadecimal 06 (decimal 6), indicating that six character pairs
139 (or ASCII bytes) follow.
140
141 · 00 00 Four character 2-byte address field, zeroes in this example.
142
143 · 48 44 52 ASCII H, D, and R - "HDR".
144
145 · 1B The checksum.
146
147 The first S1 record is comprised as follows:
148
149 · S1 S-record type S1, indicating it is a data record to be loaded at
150 a 2-byte address.
151
152 · 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
156 · 00 00 Four character 2-byte address field; hexidecimal address
157 0x0000, where the data which follows is to be loaded.
158
159 · 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
162 · 2A The checksum.
163
164 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
168 The S5 record is comprised as follows:
169
170 · S5 S-record type S5, indicating it is a count record indicating the
171 number of S1 records
172
173 · 03 Hexadecimal 03 (decimal 3), indicating that three character
174 pairs follow.
175
176 · 00 04 Hexadecimal 0004 (decimal 4), indicating that there are four
177 data records previous to this record.
178
179 · F8 The checksum.
180
181 The S9 record is comprised as follows:
182
183 · S9 S-record type S9, indicating it is a termination record.
184
185 · 03 Hexadecimal 03 (decimal 3), indicating that three character
186 pairs follow.
187
188 · 00 00 The address field, hexadecimal 0 (decimal 0) indicating the
189 starting execution address.
190
191 · 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
198 · 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
202 · 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
206 · 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), libgpsmm(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 GPSD project, which
219 added endianness clarifications.
220
221
222
223The GPSD Project 15 Jul 2005 SREC(5)