目录
1 什么是Motorola S-record
2 Motorola S-record的格式
2.1 Motorola S-record的结构
2.1.1 “Record type记录类型”的说明
2.1.2 “Record length记录长度”的说明
2.1.3 如何计算“Checksum校验和”
2.2 Record order记录顺序
2.3 Text line terminator文本行终止符
2.4 Comments注释
结尾
优质博文推荐阅读(单击下方链接,即可跳转):
点击返回「Autosar从入门到精通-实战篇」总目录
点击返回「《Autosar_BSW高阶配置》总目录」
1 什么是Motorola S-record
Motorola S-record是一种文件格式,由摩托罗拉在20世纪70年代中期为Motorola 6800处理器创建,以ASCII文本形式传达二进制信息的十六进制值,其文件格式也可能为*.SRECORD,*.SREC,*.S19,*.mot,*.S28,*.S37,*.SX,*.s,*.s1,*.s2,*.s3,*. exo,*.mxt。
Motorola S-record通常用于对microcontroller微控制器、EPROM、EEPROM和其他类型的可编程逻辑器件中的flash memory进行编程。在一个典型的应用中,compiler编译器或assembler汇编器将程序的源代码(如C或汇编语言)转换为machine code机器码,并将其输出为HEX文件。然后,程序员导入HEX文件,将机器码"刻录"到非易失性存储器non-volatile memory中,或传输到目标系统中进行加载和执行。
2 Motorola S-record的格式
2.1 Motorola S-record的结构
S | Type | Byte Count | Address | Data | Checksum |
一个SREC格式文件由一系列ASCII text record组成,一个S-record的长度将小于或等于78字节。这些record从左到右有以下结构:
举例:
1.Record start:每条record以大写字母"S"字符(ASCII 0x53)开始,代表该Record的开始;
2.Record type:一个"0"到"9"的十六进制数字字符(ASCII 0x30到0x39),定义该Record的类型;
3.Byte count:两个十六进制数字字符(既,1个字节,"00"到"FF"),表示该Record其余部分(Address + Data + Checksum)中的字节数。该段的最小值为3(16-bit address field为2字节,checksum field为1字节),最大值为255(0xFF),其"00"/"01"/"02 "是非法值;
4.Address:四/六/八个十六进制数字字符(既,2/3/4个字节),由Record type决定。Address byte以big-endian格式排列:从左往右,地址依次增加;
5.Data:2n个十六进制数字字符的序列(既,n个字节)。对于S1/S2/S3 Record,每条Record最多32个字节是典型的,因为它将适合于80个字符宽的terminal screen,尽管16个字节会更容易视觉解码特定地址的每个字节;
6.Checksum:两个十六进制数字字符(既,1个字节),是Byte count、Address和Data的两个十六进制数字字符对所代表的数值之和的最小有效字节LSB的补码。在C语言中,Sum通过以下方式转换为checksum: 0xFF - (sum & 0xFF)。
2.1.1 “Record type记录类型”的说明
下表描述了10个可能的S-record。S4是保留的,目前没有定义。S6最初是保留的,但后来被重新定义。
Record field | Record purpose | Address field | Data field | Record description |
S0 | Header | 16-bit | 适用 | 该record包含供应商特定的ASCII文本注释,表示为一系列成对的十六进制数字字符。该record的数据通常是以空尾字符串的格式出现。文本数据可以是任何东西,包括以下信息的混合:文件/模块名称、版本/修订号、日期/时间、产品名称、供应商名称、PCB上的memory代号、版权声明、签名。这是很常见的情况:48、44、52,这是字母 "H"、"D"、"R "的ASCII表示。 |
S1 | Data | 16-bit | 适用 | 该record包含从16-bit address开始的数据。该record包含的数据字节数是"Byte Count Field "最小为3("16-bit Address Field "的2个字节,"Checksum Field"的1个字节)。该record通常用于8位和16位处理器。 |
S2 | Data | 24-bit | 适用 | 该record包含从24-bit address开始的数据。该record中包含的数据字节数是 "Byte Count Field"最小为4("24-bit Address Field "的3个字节," Checksum Field "的1个字节)。该record通常用于32位处理器。 |
S3 | Data | 32-bit | 适用 | 该record包含从32-bit address开始的数据。该record包含的数据字节数是"Byte Count Field"最小为5("32-bit Address Field "的4个字节," Checksum Field"的1个字节)。该record通常用于32位处理器。 |
S4 | Reserved | — | — | 该record是保留的。 |
S5 | Count | 16-bit | 不适用 | 该可选的record包含一个S1/S2/S3 record的16-bit count。如果record count小于或等于65535(0xFFFF),则使用该record,否则将使用S6 record。 |
S6 | Count | 24-bit | 不适用 | 该可选的record包含一个S1/S2/S3 record的24-bit count。如果record count小于或等于16777215(0xFFFFFF),则使用该record。如果小于65536 (0x10000),那么将使用S5 record。 注意:这个较新的record是最近的变化(它可能不是正式的)。 |
S7 | Start Address | 32-bit | 不适用 | 该record包含32-bit address的起始执行位置。这是用来终止一系列的S3 record的。如果SREC文件只用于对一个memory设备进行编程,并且执行位置被忽略,那么可以使用一个0的地址。 |
S8 | Start Address | 24-bit | 不适用 | 该record包含24-bit address的起始执行位置。这是用来终止一系列S2 record的。如果SREC文件只用于对一个memory设备进行编程,并且执行位置被忽略,那么可以使用一个0的地址。 |
S9 | Start Address | 16-bit | 不适用 | 该record包含16-bit address的起始执行位置。这是用来终止一系列S1 record的。如果SREC文件只用于对一个memory设备进行编程,并且执行位置被忽略,那么可以使用一个0的地址。 |
2.1.2 “Record length记录长度”的说明
record count的长度随着Record field的变化而变化。历史上Unix O/S文件中的一个手册页指出:"一个S-record文件由一连串特殊格式的ASCII字符串组成。一个S-record的长度将小于或等于78字节"。"本手册页是唯一记录了总record length 78字节限制或data length 64字节限制的地方。"。
Record field = S1,4-hex-character address,64-hex-character data和2-hex-character checksum,共record count = 70-hex-character = 23 Byte(这个计数忽略了行末的字符串终止符)。
Record field = S2,6-hex-character address,64-hex-character data和2-hex-character checksum,共record count = 72-hex-character = 24 Byte(这个计数忽略了行末的字符串终止符)。
Record field = S3,8-hex-character address,64-hex-character data和2-hex-character checksum,共record count = 74-hex-character = 25 Byte(这个计数忽略了行末的字符串终止符)。
注意:
如果忽略78字符的历史限制,一个S-record的最大长度将是514个字符。假设字节数为0xFF(255),则Record Type field为2,Byte Count field为2,Address / Data / Checksum field为2*255,共514个字符。
以下图S0为例,Address + Data + Checksum长度超过了78字符:
2.1.3 如何计算“Checksum校验和”
下面的record为例,来介绍Checksum的计算:
S10DFC004303030B01004259010104
Checksum计算过程:
1.对所有Byte count + Address + Data十六进制字节求和:0D + FC + 00 + 43 + 03 + 03 + 0B + 01 + 00 + 42 + 59 + 01 + 01 = 1FB。
2.保留最后一个LSB字节,即十六进制字节FB,其二进制为1111 1011。
3. LSB的二进制补码为0000 0100,即十六进制字节04。或checksum=FF - FB = 04
2.2 Record order记录顺序
尽管一些Unix文档指出 "文件中S-record的顺序并不重要,也不需要假定特定的顺序",但实际上大多数软件都对SREC record进行了排序。
典型的record顺序是从一个(有时是可选的)S0 header record开始,接着是一个或多个S1/S2/S3 data record的序列,可能有一个可选的S5/S6 count record,最后是一个适当的S7/S8/S9 termination record。
16-bit address record:
S03E0000433A5C55736572735C757365725C4465736B746F705C424E5C455642434D5C62696E5C53565F43383133335F62335F332E31312E315F4259312E31C6
S123C000CF2600C6055B134A81E6FE4A81BCFE0005C015DA670FE60018E60FA000020C0FE0
S123C020B0000E3C0FC0000EC70FD0000E1600000000000000000000000000000000C70094
S123C040FC00E900E200E400E000E500E700EA00EB00E800EF00EE00EC00C400C500C900AD
......
S123FBC00600C0003013880000A5000001F403E803E800000400FFFFFFFFFFFFFFFFFFFF26
S123FBE0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF03DA954962
S10DFC004303030B01004259010104
S110FC203230313630363232313732360070
S105FF7AD7FEAC
S105FF8AD8E4B5
S105FFD4D872DD
S105FFDED9AE96
S107FFE4D960D9B54E
S107FFF0D722D871C7
S105FFFEC0003D
……
S9030000FC
24-bit address record:
S2240F7CE04E128840E5D49440D6CD9340866194408B66AC402D41AD407729B240462FB24059
S2240F7D00D70CA940D70CA940D70CA94041A7B14041A7B14041A7B140DAADC7401151AB4085
S2240F7D20D266BD40B8EDBF406A17A540BDFC8A4021F187404E128840E5D49440D6CD934069
S2240F7D40866194408B66AC402D41AD407729B240462FB240D70CA940D70CA940D70CA940BF
S2240F7D6041A7B14041A7B14041A7B140DAADC7401151AB40D266BD40B8EDBF406A17A5404A
……
S804000000FB
32-bit address record:
S00600006C7463B6
S32580054924203889A4B409A57470D882186DFF12E6857F3EA060FC54CF160A74CF6DFFD0E661
S3258005494454CF6F1F16806DFF05E6857F70D8C82F14FF5E1454CF16033C0454CF160B960804
S3258005496474CF6DFFBDE654CF74AF820854AFDF085482857670D8857F02B082044964080A88
S3258005498460FFD445857F06B054F060F2095F02090245D46754217E05095006095F012500E6
S325800549A4857F0AB0821560F5857F0EB05450745FD4450951020974F1D4450951020974F1BF
S325800549C4D44F09F1060974218201A0BF8F11003082320F32002026027625DA020F3F00F0E3
S325800549E4A6F4C211FCF4BD074B00F657857F0AB060FF857F0EB074FFD46F857F0AB0A07408
……
S30FA00F20C0916000E8D9EE5EEFDC0E8A
S30FA00F20E0916000E8D9EE72DFDC0E66
S705A0048020B6
2.3 Text line terminator文本行终止符
SREC Record被一个或多个ASCII行termination character终止符隔开,使每条Record单独出现在一个文本行上。这通过视觉上划分Record的边界来提高可读性,同时也提供了Record之间的填充,可以用来提高机器的解析效率。创建HEX Record的程序通常使用符合其操作系统惯例的行终止符。例如,Linux程序使用一个LF字符(line feed换行,ASCII字符值为0x0A)来终止行,而Windows程序使用一个CR字符(carriage return回车,ASCII字符值为0x0D),后面跟着一个LF字符。
2.4 Comments注释
除了S0 header record中的ASCII-hex转换的注释外,SREC文件格式不正式支持人类可读的ASCII注释,尽管有些软件忽略了所有不以 "S "开头的行和/或忽略了Checksum field(因此尾部文本有时被用于(不兼容)注释)后的所有文本。
部分内容摘自:
SREC (file format) - 维基百科https://en.wikipedia.org/wiki/SREC_%28file_format%29
结尾
获取更多“汽车电子资讯”和“工具链使用”,
请关注CSDN博客“汽车电子助手”,做您的好助手。