S-RECORD OUTPUT FORMAT
The S-record format for output modules was devised for the purpose of encoding
programs or data files in a printable format for transportation between
computer systems. The transportation process can thus be visually monitored
and the S-records can be more easily edited.
S RECORD CONTENT
When viewed by the user, S-records are essentially character strings made of
several fields which identify the record type, record length, memory address,
code/data and checksum. Each byte of binary data is encoded as a 2-character
hexadecimal number; the first character representing the high-order 4 bits,
and the second the low-order 4 bits of the byte.
The five fields which comprise an S-record are shown below:
type | record length | address | code/data | checksum
Where the fields are composed as follows:
Printable
Field Characters Contents
type 2 S-records type -- S0, S1, etc.
record length 2 The count of the character pairs in the
record, excluding type and record
length.
address 4, 6, or 8 The 2-, 3-, or 4-byte address at which
the data field is to be loaded into
memory.
code/data 0-n From 0 to n bytes of executable code,
memory-loadable data, or descriptive
information. For compatibility with
teletypewriters, some programs may
limit the number of bytes to as few as 28
(56 printable characters in the S-record).
checksum 2 The least significant byte of the one's
complement of the sum of the values
represented by the pairs of characters
making up the records length, address,
and the code/data fields.
Each record may be terminated with a CR/LF/NULL. Additionally, an S-record
may have an initial field to accommodate other data such as line numbers
generated by some time-sharing systems. An S-record file is a normal ASCII
text file in the operating system in which it resides.
Accuracy of transmission is ensured by the record length (byte count) and
checksum fields.
S-RECORD TYPES
Eight types of S-records have been defined to accommodate the several needs
of the encoding, transportation and decoding functions. The various Motorola
upload, download and other records transportation control programs, as well as
cross assemblers, linkers and other file-creating or debugging programs,
utilize only those S-records which serve the purpose of the program. For
specific information on which S-records are supported by a particular program,
the user's manual for the program must be consulted. 332Bug supports S0, S1,
S2, S3, S7, S8, and S9 records.
An S-record format module may contain S-records of the following types:
S0 The header record for each block of S-records, The code/data.field may
contain any descriptive information identifying the following block of
S-records. The address field is normally zeros.
S1 A record containing code/data and the 2-byte address at which the
code/data is to reside.
S2 A record containing code/data and the 3-byte address at which the
code/data is to reside.
S3 A record containing code/data and the 4-byte address at which the
code/data is to reside.
S5 A record containing the number of S1, S2, and S3 records trans-mitted
in a particular block. This count appears in the address field.
There is no code/data field.
S7 A termination record for a block of S3 records, The address field may
optionally contain the 4-byte address of the instruction to which
control is passed. There is no code/data field.
S8 A termination record for a block of S2 records. The address field may
optionally contain the 3-byte address of the instruction to which
control is passed. There is no code/data field.
S9 A termination record for a block of S1 records. The address field may
optionally contain the 2-byte address of the instruction to which
control is passed. If not specified, the first entry point
specification encountered in the object module input will be used.
There is no code/data field.
Only one termination record is used for each block of S-records. S7 and S8
records are usually used only when control is to be passed to a 3 or 4 byte
address. Normally, only one header record is used, although it is possible
for multiple header records to occur.
S-RECORDS CREATION
S-record format files may be produced by dump utilities, debuggers, linkage
editors, cross assemblers or cross linkers. Several programs are available
for downloading a file in S-record format from a host system to a microprocessor
-based system.
EXAMPLE
Shown below is a typical S-record format module, as printed or displayed:
S00600004844521B
S1130000285F245F2212226A000424290008237C2A
S11300100002000800082629001853812341001813
S113002041E900084E42234300182342000824A952
S113003000144ED492
S9030000FC
The module consists of one S0 record, four S1 records, and an S9 record.
The S0 record is comprised of the following character pairs:
S0 S-record type S0, indicating that it is a header record.
06 Hexadecimal 06 (decimal 6), indicating that six character pairs (or ASCII
bytes) follow.
00 Four-character, 2-byte, address field; zeros in this example.
00
48
44 ASCII H, D and R - "HDR".
52
1B The checksum.
The first S1 record is explained as follows:
S1 S-record type S1, indicating that it is a code/data record to be
loaded/verified at a 2-byte address.
13 Hexadecimal 13 (decimal 19), indicating that 19 character pairs,
representing 19 bytes of binary data, follow.
00 Four-character, 2-byte, address field; hexadecimal address
00 0000, where the data which follows is to be loaded.
The next 16 character pairs of the first S1 record are the ASCII bytes of
the actual program code/data. In this assembly language example, the
hexadecimal opcodes of the program are written in sequence in the code/data
fields of the S1 records:
OPCODE INSTRUCTION
285F MOVE.L (A7)+,A4
245F MOVE.L (A7)+,A2
2212 MOVE.L (A2),D1
226A0004 MOVE.L 4(A2),A1
24290008 MOVE.L FUNCTION(A1),D2
237C MOVE.L #FORCEFUNC,FUNCTION(A1)
(The balance of this code is continued in the code/data fields of the
remaining S1 records and stored in memory.)
2A The checksum of the first S1 record.
The second and third S1 records also each contain $13 (19) character pairs
and are ended with checksums 13 and 52 respectively. The fourth S1 record
contains 07 character pairs and has a checksum of 92.
The S9 record is explained as follows:
S9 S-record type S9, indicating that it is a termination record.
03 Hexadecimal 03, indicating that three character pairs (3 bytes) follow.
00
00 The address field, zeros.
FC The checksum of the S9 record.
Each printable character in an S-record is encoded in a hexadecimal (ASCII in
this example) representation of the binary bits which are actually transmitted.
[SSU Home Page] [SSU CS Department] [ CS Dept webmaster ] 12/22/97.