Motorola S-Record Checksum Validator
Use this Motorola S-Record Checksum Validator to validate SREC or S-record data, identify the record type, verify the count field, decode the address, extract data bytes, calculate the expected checksum, and generate a corrected Motorola S-record when necessary.
-
-
-
-
What Is a Motorola S-Record Checksum Validator?
A Motorola S-Record Checksum Validator checks the structure and checksum of an individual Motorola S-record, also commonly called an SREC, S19, S28, or S37 record depending on the file and address format.
Motorola S-record files represent binary information as printable hexadecimal text. They are widely encountered in embedded systems, firmware programming, microcontrollers, bootloaders, memory programmers, automotive electronics, and legacy development environments.
This validator does more than compare the final checksum byte. It identifies the S-record type, determines the required address width, verifies the count field, extracts the address and data bytes, calculates the expected checksum, and creates a corrected record if the supplied checksum is wrong.
How to Use the Motorola S-Record Validator
Enter one complete record beginning with S followed by its record-type digit.
The calculator checks whether the count byte agrees with the number of address, data, and checksum bytes supplied.
The address width is selected automatically according to the S-record type.
The count, address, and data bytes are summed and the low eight bits are complemented.
The supplied checksum is compared with the independently calculated checksum.
Motorola S-Record Format
A Motorola S-record is an ASCII line containing a record identifier followed by hexadecimal fields.
Unlike Intel HEX, the number of address bytes is not fixed for every S-record type. The address width depends on the type of record being decoded.
Motorola S-Record Types
| Type | Purpose | Address Size | Typical Use |
|---|---|---|---|
| S0 | Header | 2 bytes | File/module identification information |
| S1 | Data | 2 bytes | 16-bit address data record |
| S2 | Data | 3 bytes | 24-bit address data record |
| S3 | Data | 4 bytes | 32-bit address data record |
| S5 | Count | 2 bytes | Number of preceding data records |
| S6 | Count | 3 bytes | Extended data-record count |
| S7 | Termination | 4 bytes | Start address for S3-based files |
| S8 | Termination | 3 bytes | Start address for S2-based files |
| S9 | Termination | 2 bytes | Start address for S1-based files |
How Is the Motorola S-Record Checksum Calculated?
The Motorola S-record checksum is an 8-bit one’s-complement checksum. Start with the count byte, then add every address byte and every data byte.
This is different from Intel HEX. Intel HEX uses a two’s-complement checksum, whereas Motorola S-record uses the one’s complement of the least-significant byte of the sum.
Motorola S-Record Checksum Validation Rule
A convenient validation method is to add the count, address, data, and checksum bytes together.
Because the checksum is the one’s complement of the low byte of the preceding
sum, including it makes the low eight bits of the complete sum equal
FF.
What Does the S-Record Count Byte Mean?
The count field appears immediately after the record type. It is one byte, represented by two hexadecimal characters.
The important detail is that the S-record count does not simply represent the number of data bytes. It represents the number of binary bytes that follow the count field in that record.
This validator checks that relationship before attempting to accept the checksum as valid.
S1, S2 and S3 Data Records
S1 Record
Uses a two-byte address, allowing a 16-bit address field. S1 is commonly associated with S19 files.
S2 Record
Uses a three-byte address and therefore supports a larger address range than S1.
S3 Record
Uses a four-byte address and can represent a full 32-bit address field.
Automatic Detection
The calculator reads the record type and automatically applies the correct address length.
Motorola S1 Record Example
Consider this S1 record:
Because S1 uses a two-byte address, the calculator interprets the next four hexadecimal characters after the count as the address. The remaining bytes, except for the final checksum byte, are data.
S7, S8 and S9 Termination Records
Termination records commonly appear at the end of an S-record file and can contain the execution start address.
| Record | Address Bytes | Associated Data Type |
|---|---|---|
| S7 | 4 | Typically terminates a sequence using S3 data records |
| S8 | 3 | Typically terminates a sequence using S2 data records |
| S9 | 2 | Typically terminates a sequence using S1 data records |
A familiar minimal S9 termination record is
S9030000FC. Its count is 03 because two address bytes and one
checksum byte follow the count field.
Why Address Length Matters
Checksum validation requires knowing exactly which bytes are address bytes and which are data bytes. Motorola S-record types use different address widths.
For example, S1 uses two address bytes while S3 uses four. Treating an S3 record as an S1 record would produce an incorrect data boundary and misleading decoded information.
The validator therefore determines the address length from the record type before displaying the address and data fields.
Motorola S-Record vs Intel HEX
| Feature | Motorola S-Record | Intel HEX |
|---|---|---|
| Line Prefix | S plus record digit | Colon (:) |
| Address Width | Depends on record type | 16-bit field per record |
| Checksum | One’s complement | Two’s complement |
| Data Records | S1, S2, S3 | Type 00 |
| Termination | S7, S8, S9 | Type 01 EOF plus optional start-address records |
Both formats encode binary firmware as hexadecimal text, but their record structures and checksum rules are different. A validator must therefore parse each format according to its own rules.
SREC, S19, S28 and S37 Files
Several filename extensions are associated with Motorola S-record data.
.srec, .s19, .s28, and
.s37 may all be encountered in embedded-development workflows.
S19
Often associated with S1 data records using two-byte addresses.
S28
Often associated with S2 data records using three-byte addresses.
S37
Often associated with S3 data records using four-byte addresses.
SREC
A general filename extension used for Motorola S-record formatted data.
The extension alone should not replace parsing the actual records. This tool determines each record’s structure from the S-record type itself.
Why an S-Record Checksum Can Be Invalid
Changed Data
A modified data byte changes the sum and therefore the expected checksum.
Changed Address
Every address byte participates in the checksum calculation.
Wrong Count
An incorrect count field changes both the structure and checksum.
Truncated Line
Missing hexadecimal characters can remove data or the final checksum byte.
Manual Editing
Changing a firmware record requires recalculating its checksum.
Wrong Algorithm
Using an Intel HEX or CRC checksum formula will not produce the SREC checksum.
Common Motorola S-Record Checksum Mistakes
S-record checksum generation uses one’s complement of the low-byte sum.
The count byte itself participates in the checksum calculation.
All address bytes must be added when calculating the checksum.
The count field includes address, data, and checksum bytes.
S2/S8 use three address bytes, while S3/S7 use four.
Hexadecimal pairs must first be decoded into their binary byte values.
Where Motorola S-Records Are Used
Embedded Firmware
S-record files can transport compiled firmware with explicit memory addresses.
Microcontrollers
Programming and debugging utilities may import SREC firmware images.
Automotive Systems
S-record files are encountered in ECU, controller, and embedded programming workflows.
Bootloaders
A bootloader can parse records and place data at specified memory locations.
Memory Programmers
EPROM, EEPROM, flash, and other programming systems may accept S-record input.
Firmware Debugging
Engineers can inspect addresses, data boundaries, counts, and checksums.
Motorola S-Record Checksum Validator FAQs
What is a Motorola S-record?
What is an SREC file?
How is an S-record checksum calculated?
Is Motorola S-record checksum one’s complement?
Does the count byte participate in the checksum?
Does the S-record count include the checksum?
What is an S1 record?
What is an S2 record?
What is an S3 record?
What is an S9 record?
What does S9030000FC mean?
What should a valid complete S-record sum equal?
Is S-record checksum the same as Intel HEX checksum?
Is SREC checksum a CRC?
Can this tool correct a bad S-record checksum?
Can this tool validate S0 through S9?
Validate Motorola S-Records Instantly
Paste an SREC record to check its type, byte count, address, data and checksum. If the supplied checksum is incorrect, the validator calculates the expected value and generates a corrected Motorola S-record.