CRC校验 | 程序如何检查自身完整性？（1）

在一些比较严格的行业里面，不是说你的程序能完成必要功能就可以，还需要添加一些额外的功能，比如最常见的看门狗功能，它可以在程序死机时完成重启，但也仅仅如此而已。很多异常它是无法检查的，比如程序偶然跑飞，ram 异常、flash异常等其他问题，只有程序hardfault或者其他严重问题导致程无法喂狗时才能起作用。

所以有些产品为了保障安全，会增加安规代码，保证程序能够正常运行（UL/CSA/IEC 60730-1/60335-1 B类认证）。

自检内容

MCU 安全检查一般包括以下几个方面：

1、CPU 自测（寄存器测试）

2、系统时钟频率测量（保证时钟正常工作，不快也不慢，GD 芯片在短路晶振后，程序暂停运行，无法检查，但是 ST 芯片会自动切换到内部时钟，可以由程序检查这种异常）

3、RAM 自检

4、FLASH 存储器完整性检查

5、独立看门狗、窗口看门狗检查

6、安全相关变量检查

7、中断检查

8、I/O 口检查

9、栈检查

10、程序流程控制

11、AD 口检查

你会发现真要完成这份安规代码，难度不是一般的大，不过一般芯片厂商会提供相关参考例程和相关文档，但不是说有了这些资料就完全没有问题了。

比如 ST 提供了一个参考例子，但是它使用的 HAL 库（事实上它还有标准库，当时不知道），如果原本程序用的标准库，那么就需要进行移植，这个工作量也不是一般大（首先要能理解程序，才能进行正确移植，而里面的逻辑还是很复杂的）。如果你不想移植，还有一个办法是使用 lib 库，就是将相关功能打包成一个库，虽然程序会大一些（毕竟很多底层代码和原来的重复了），但确实是比较简单的方法（前提是 flash 够大）。

鱼鹰走的是第一条路，移植，并且将相关的底层代码提供了接口，这样不管是用标准库还是 HAL 库，只要自己实现这这些特定的接口即可完成。

另外，参考例子只是实现了一个最基本的功能，在真正的产品不一定能适用。比如你的程序负载大，而里面为了测量时钟频率，几百微秒时间就要进入一次中断（即使是分频后），如果刚好在中断产生时，其他程序禁用了中断，运行这些代码有可能就会出现问题，很容易错过中断而导致复位。

在我一开始移植的时候就是如此，在一个简单的程序里面可以正常运行很长时间，但是移植到产品工程里面，时不时出现时钟检查不通过的时候，导致程序不停重启，最终鱼鹰通过 DMA 传输的方式解决了这个问题，再也不会因为时钟检查不通过导致重启了。

另外一个难点是对 .sct （分散加载）文件的理解，这个会在后面介绍。

安规相关的内容实在是太多，要写的话可以写成一个系列了，如果各位道友感兴趣的话，多多转发支持一下鱼鹰，如果效果不错，鱼鹰会考虑完成后续的其它部分。（这里有一份比较全面但简单一些的参考文章可以看看 http://news.eeworld.com.cn/mp/STM32/a80041.jspx，只介绍如何做，没怎么介绍为什么这么做）

资料

ST 相关资料可以查看以下内容（www.st.com，下载时需要注册邮箱才行，鱼鹰公众号后台提供了部分资料，可自行领取）

《AN4435 应用笔记》中文版，《AN277》（ROM Self-Test）

STM8-SafeCLASSB

https://www.st.com/en/embedded-software/stm8-safeclassb.html

STM32-CLASSB-SPL(基于标准外设库)

https://www.st.com/en/embedded-software/stm32-classb-spl.html#tools-software

X-CUBE-CLASSB(基于HAL库)

https://www.st.com/en/embedded-software/x-cube-classb.html（不同版本有不同芯片，比如 2.2.0 版本的是 Fx 相关的，2.3.0 是H7、G0 相关的）

当然国产芯片也一般会提供例程。

本篇笔记只介绍其中一个内容，即 FLASH 检查，换句话说就是程序完整性检查。

FLASH 检查

我们以比较复杂的 boot + app + rtos ，开发环境 keil 、stm32f103 为例介绍相关知识。

一般 boot 和 app 部分是用不同工程管理的，所以 app 部分代码只能检查自身的完整性，而不能检查 boot 部分。

并且 app 的 flash 区也不是完全检查的，有一小部分是也没法检查的，但这并不影响它的功能（既然已经跳转到 app 里面了，那么 boot 部分 flash 即使在运行时有问题也不影响功能，而如果变量初始值的flash有问题就是关键变量检查的问题了）。

现在就是如何检查的问题了。

如何检查 | 基本原理

校验手段有很多，比如 和校验、MD5 校验、CRC 校验，这里我们使用 CRC，因为一般芯片内部会内置该外设硬件计算（如果没有，可以纯 CPU 计算）。

然后我们需要了解完整性检查的基本原理。

所谓程序完整性检查，就是在下载代码前，先用工具把要校验的部分通过计算公式计算出一个值，保存在某个地方（flash），然后程序在运行的时候，自己也去读取要校验的 flash 部分，通过同样的计算公式计算出一个值，然后将这个值和保存在 flash 里面的值进行比较，就可以看出代码是否存在异常了，有异常及时处理，没有异常就继续重新检查。

而检查分成两个步骤：

1、开机时，一次性完成所有计算，保证运行前完整。

2、正常运行时，定时计算，每次计算一个小块，当计算完最后一块时才比较结果，成功就重新继续计算，失败则终止程序运行，周而往复（计算需要较长的时间，分时计算可以不影响程序正常功能），这样可以保证程序在运行时也能检查 FLASH 的完整性，防止 FLASH 运行过程中破坏掉。

现在有个问题，CRC 保存在何处才是合适的？

随便保存在一个地方肯定是不行的。假设这个位置在要校验代码部分的里面，那么当工具计算这个值时，又会篡改掉校验部分里面的数据（因为你把 CRC 值放到里面了），那么你的程序校验时，肯定不通过，因为你读了一个被改变的 CRC 值。所以这个值一定要放在代码的最后面才行。

另外前面说过，运行时会一小块一小块，所以要保证你的 CRC 值存放位置应该在小块大小的边界位置上。比如一次计算 16 字节，那你存放的位置应该是 16 的倍数才是正常的。

所以，CRC 存放位置存在这两个限制。

另外，如何提前计算好 CRC 的值呢？IAR 内置该功能，而 KEIL 我们可以借助强大的开源工具 SRecord《功能强大的 HEX 开源转换工具，你值得拥有》（一转眼，这篇文章差不多鸽了四个多月了）帮助我们计算。

基本知识都了解的差不多了，接下来就是如何操作的问题。

实操

1、固定 CRC 位置。

我们可以在启动文件的最后加入以下代码（END 前）

这里默认是 0x3D334398，但会在后续修改成正确的 CRC 值

;*******************************************************************************
; User Checksum - must be placed at the end of memory
;*******************************************************************************
                AREA    CHECKSUM, DATA, READONLY, ALIGN=6
                EXPORT  __Check_Sum
; Alignement here must correspond to the size of tested block at FLASH run time test (16 words ~ 64 bytes)!!!
                ALIGN
__Check_Sum     DCD     0x3D334398;                  ; Check sum computed externaly

这里保证了 __Check_Sum 的地址是 2 ^ 6 大小对齐，所以你的计算小块可以这个大小，当然也可以小一些，比如 2 ^ 5 等。这样就可以将检查部分分成固定的小块，不会多，也不会少，刚刚好（必须）。

那么如何将这个地址固定在代码最后呢？这个时候就需要我们的 .sct 文件发挥作用了

（ClassB_stm32F10x.sct）。
ER_IROM1 0x08000000 0x10000  {  ; load address = execution address
      *.o (RESET, +First)
      *(InRoot$$Sections)
      .ANY (+RO)
      *.o (CHECKSUM, +Last) ;放置在最后
    }

我们用了 +Last 将其放置在代码的最后部分，你想把它放置在 bin 文件最后面？暂时鱼鹰还没想到怎么做，有知道的道友可以告诉鱼鹰（通过 sct 的方式）。

2、CRC 计算脚本

在 windows 叫批处理，.bat ，我们可以在参考例程中找到。crc_gen_keil.bat

我们需要需改三个位置

第一个是你的计算工具的路径，里面应该要有计算工具。

第二个就是你的工程名字，我们通过下面位置确定（鱼鹰用的 Main）：

最后是工程路径。一般在 Objects 文件夹里面，而 map 文件一般在 Listings 文件夹里面。

说白了，这些变量就是为了让脚本能够找到 map、hex 文件和工具。但一般默认工程，这两个文件可能不在一个文件夹里面，所以我们可以对例子中的批处理文件 crc_gen_keil.bat 进行适当修改。

map 文件的作用是为了让脚本能够搜索到 __Check_Sum 的地址，然后就可以计算 CRC 并修改 HEX 里面这个值了。

另外还有新增了一个变量 HEX_ADRR，当我们的计算位置不是从 0x08000000 开始时（比如 app 起始地址在 0x08009000），我们就可以修改这个变量值。还有我们希望在计算完并修改 CRC 后可以自己生成 bin 文件方便我们更新固件，还需要加入转化成 bin 的命令。

其中为了下载修改（CRC）后的 HEX 文件，我们还需要简单修改一下，用于判断工具是否存在，不存在，直接删除 hex 和 axf 文件（防止下载未修改的文件）。

%xxx% 类似脚本中的 $xxx

if not exist %SREC_PATH% (
    echo %SREC_PATH% is not exit, exit
    echo ----------------------------------------del %INPUT_HEX% -- %AXF_FILE% ---------------
    del %INPUT_HEX% %AXF_FILE%
    exit
)