I-care 集团在Wi-care智能工业预测性维护系统中采用STM32WB5MMGH6无线模块

机器学习 (ML) 在服务器和移动应用中已经风靡多年，现在这种趋势已蔓延到边缘设备，并且变得突出。由于边缘设备需要节能，因此开发人员需要学习和了解如何将ML模型部署到基于微控制器的系统中。

在微控制器上运行的ML模型通常被称为tinyML。然而，将模型部署到微控制器并非易事，但它正在变得越来越容易，没有经过任何专业培训的开发人员也能在规定时间完成部署。

1、前言

最近有客户询问，能否使用 STM32CubeIDE 在编译时通过设置某个编译选项，让STM32 应用与存储位置无关。这样的优势是能使同一个固件被烧在 STM32 Flash 里的不同位置， 而在系统 Bootloader 里只需要跳到相应的位置就可以正常执行固件代码。客户希望STM32 代码从 Flash 里执行，不复制到 RAM 里；客户希望是一个完整的映像，而不仅仅是其中某个函数做到了位置无关。

2、分析

在嵌入式场景下，不一定有操作系统。即使有操作系统，一般也是 RTOS。一般 RTOS没有一个通用的程序加载器。因此，存储位置无关的需求，在这时可以说无关紧要。但是，如果客户需要进行在线固件更新，例如 IoT 应用的固件升级，那么位置无关就存在价值了。位置无关之后，对于不同的软件版本，不需要频繁的为烧写位置的反复改变而修改编译链接脚本。也不需要在代码里显式的在两个 Bank 之间进行切换。

最简单的情况是所有的代码都复制到内存执行。因为 Flash 的功能只是进行存储，自然对 Flash 的位置没有任何要求。但大部分 MCU 用户面临的真实案例都是 Flash 比较大，例如 ，1M 字节 ；RAM 比较小，例如，128K 字节。在这种情况下，代码在 Flash 原地执行就是一个必须的选择。Flash 位置改变，会影响从 Bootloader 跳转之后的固件执行时的 PC 指针，也就是 PC指针值会发生相应的变化。位置无关的原理，是让应用程序经过编译后所生成的映像，其中的代码和数据，都是基于相对代码的位置进行引用。那么，当应用被搬到不同位置时，他们的相对位置不变，从而执行不受影响。

代码和数据基于绝对地址还是基于相对地址，是由编译器所决定。以客户要求的

STM32CubeIDE 编译工具为例，我们可以看到在[Project]->[Properties]->[C/C++ Build]->[Settings]->[Tool Settings]->[MCU GCC Compiler]->[Miscellaneous]已经有一项[Position Independent Code (-fPIC)]。

是否只要选一下-fPIC 选项就大功告成了呢？答案是没有那么简单。

事实上，对于完整应用程序工程，用户应该经过这些步骤将其变成位置无关：• 选择正确的编译器选项

• 去掉或者替换掉那些包含绝对位置的库文件

• 修改代码中的 Flash 绝对地址（这里以 STM32H7 的 CRC_Example 例程为例，其他情况下有可能要修改更多）

• 在 startup_xxx.s 汇编代码里的 sidata

• 在 system_xxx.c 里的 SCB->VTOR 以及中断向量表内容

• GOT

对于完整工程，要正确的跳转到应用程序进行执行，还需要由 Bootloader 向应用程序提供或者由应用程序在链接时自身解析计算，得到以下信息：

• Flash 偏移量

• 中断向量表的开始以及结束地址

• GOT 的开始以及结束地址

我们接下来就举例说明这些步骤。

3、步骤

3.1. 选择正确的编译器选项

如果我们不使用任何编译选项，编出来的代码会怎么样？我们可以通过.list 文件进行查看。.list 文件在 STM32 例程中默认生成，如果没有请勾选如下选项， 在 [Project]->[Properties]->[C/C++ Build]->[Settings]->[Tool Settings]->[MCU Post Build outputs]->[Generate list file]，可参考下图。

我们看到代码中直接使用了变量的绝对地址，例如 0x2000 0028。我们不要被 literal pool 文字池的使用所迷惑，那个基于 PC 的操作只是为了取变量的绝对地址，例如， 0x2000 0028，并没有将绝对地址变成相对地址。

当然大家说这里是 RAM 地址，没有关系。我们选择这个函数来说明，是因为位置无关的编译器选项是不区分 RAM 还是 Flash 里的变量，而这个函数最简单容易理解。如果我们查看另外一个复杂一点的函数，例如，HAL_RCC_ClockConfig，我们可以看到以下对Flash 里变量的直接使用。这就不妙了，因为一旦改变了 Flash 下载的位置，在绝对地址处就取不出变量的真实内容了。

我们没有办法一个一个查找修改所有的变量。当然这里的变量是指全局变量。如果要修改，我们希望编译器能把他们集中在一起。对于此，编译器提供了多个编译选项。例如，PIC 是位置无关代码， PIE 是位置无关执行。PIC 和 PIE 这两者类似，但是存在一个显著的差异是 PIE 会对部分全局变量优化。我们可以观察到用两种不同编译选项的效果。

其中 80004C0 地址处包含的是 GOT 自身的偏移量，存在 r2 里，要在两次取全局变量 uwTickFreq 和 uwTick 时引用。GCC 编译器引入 GOT 全局偏移量表来解决全局变量的绝对地址的问题。在之前对绝对地址的直接使用，现在被转化成先取得 GOT 入口相对于 PC 的偏移，再获得实际变量相对于 GOT 入口的偏移，从而得到实际变量的地址。计算公式如下：

实际变量的绝对地址=PC + GOT 相对于 PC 的偏移 + 变量地址相对于 GOT 的偏移

GOT 只有一个，如果代码放在不同的位置，代码自身就可以根据 Bootloader 传递过来的信息，或者自行计算来对 GOT 进行更新。这样变量的地址就和新的 Flash 偏移相匹配。

这里可以看到 80004c0 对应的 uwTick（可以从 str 指令结合 C 语言源代码快速知道它对应于 uwTick）不再使用 GOT 偏移，而是相对于 PC 的偏移（与前文相比，多了一条指令 “add r3,pc”）。换句话说，PIE 对局部的全局变量做了优化。这个优化显然不是我们所需要的。因为如此以来，RAM 变量的地址就会随着 PC 的不同而不同。而我们则希望所有对RAM 的用法不发生变化。

为了能够修改 GOT 内容，我们选择将 GOT 最终存放在 RAM 中，导致代码中对 GOT的寻址也是使用了相对于 PC 的偏移。而因为 RAM 有限，或者因为没有虚拟内存的缘故，我们不希望 RAM 的用法有所不同，否则，可能代价很大。这时，一旦 Flash 代码位置发生变化引起 PC 指针变化，GOT 就无法找到。因此，即使我们不使用 PIE，PIC 也没有办法单独使用。为了确保没有任何存放在 RAM 里的变量的位置是相对于 PC 的偏移。我们应该使用如下所有编译选项，single-pic-base 让系统只使用一个 PIC 基址，就是下文反汇编中看到r9；no-pic-data-is-text-relative 则让编译器不要让任何变量相对于 PC 寻址。

这样实际变量的绝对地址，就变成实际变量的绝对地址=PIC 基址 + GOT 相对于 PIC 基址的偏移 + 变量地址相对于 GOT的偏移使用以上编译选项，这样我们看到 HAL_IncTick 就如下所示：

这样所有在 RAM 里的全局变量都是相对于 GOT 的偏移。注意，这个时候你编译出来的代码现在没有办法进行测试，尽管你只是改了编译选项。这是因为 PIC 的基址需要你通过寄存器 r9 显式指定。在本例中，我们在链接脚本里如下定义 GOT 的位置：

因此，我们可以很容易的从.map 文件中获得 GOT_START 的 RAM 地址，0x2000 0000，它就是 PIC 的基址。如果想测试编译器选项是否如我们所期望，我们可以在Reset_Handler 开始部分加上如下语句（参考后文内存布局的代码）：

经过测试，我们可以确信，编译器选项的改动对我们最终执行结果没有影响。

值得注意的是，STM32 用户的代码，例如 RTOS 的移植， 也可能使用寄存器 r9。在这种情况，用户应当解决冲突。一般情况寄存器 r9 对应用程序并不是必要的。

3.2. 去掉或者替换掉那些包含绝对位置的库文件

我们要将位置无关的库去掉或者替换掉。在 STM32 参考代码里，我们需要

startup_xxx.s 里 C 库调用去掉。示例如下：

3.3. 修改 Flash 绝对地址

3.3.1. 内存布局

如果要对代码中的 Flash 绝对地址进行修改，我们需要知道存放 Flash 绝对地址的 RAM起始和结束地址，以及需要增加或减少的 Flash 偏移量。存放 Flash 绝对地址的 RAM 起始和结束地址，在编译时可以让应用代码本身借助自身链接脚本在链接时导出的变量得到，然后由应用程序在运行时存放在 RAM 中的固定位置；也可以在编译后从.map 文件或使用工具解析 elf 文件获得，然后作为应用程序一部分的元信息，例如，给应用程序加个头部存放元信息，由 Bootloader 下载并解析，将其放入到 RAM 固定位置。

我们规划在一段 RAM 里按如下顺序存放如下元信息，它可以是应用程序本身在最初阶段自我存放在这里，也可以简单的由 Bootloader 解析元信息后，跳转到应用程序之前就存放在这里。

我们在前文已经在链接脚本中定义了 GOT_START 和 GOT_END，我们还需要在链接脚本中定义 VT_START 和 VT_END。如下图所示：

如果我们希望 Bootloader 仅仅是做简单的跳转，我们可以将规划这段内存的工作，交给应用程序的初始化部分（在 “ldr sp, =_estack”之前）。假定 0x0 处对应为 0x2400 0000，参考代码如下：

3.3.2. 汇编代码

3.3.2.1. _sidata

在默认的 STM32 工程中，还有一些对变量绝对地址的使用。在 startup_xxx.s 有许多地方使用绝对地址，它们不能被编译器收集到 GOT 中。其中，默认在链接脚本里的_sidata，标志 flash 里 RAM 数据区的 Flash 位置，需要修改。

注意，变量绝对地址本身不是个问题，而对它解应用，取它的内容才会发生错误。而这里的 _sidata 是要被初始化代码使用，目的是将 Flash 的内容搬移到 RAM 里。我们显然要对_sidata 进行修改，否则无法取得正确的内容到 RAM 里。

根据前文的内存布局，我们可以把 Flash 的偏移量从内存中放置在寄存器 r8 里，例如：

则我们只需要一行简单的代码 “add r3,r8” 就可以修正_sidata 的地址。

3.3.3. C 代码

3.3.3.1. 公共函数

如果一段内存的数据都是硬编码，我们只需要一个公共函数就可以对其循环进行修正。我们需要知道什么样的地址之外不是 Flash 地址，那么就对这样的值不做修改。例如，我们定义 0x1fff ffff 之外的就不是 Falsh 地址，相应的宏定义如下：

3.3.3.2. SCB->VTOR

在 C 语言中如果使用赋值语句进行硬编码，编译器也无法进行收集。例如在

system_stm32xxxx.c 中的 SystemInit 有如下语句：

中断向量表相关的内容需要修改，包括两部分：

• 中断向量表的内存位置

• 中断向量表的内容

我们应该将中断向量表复制到 RAM 里，通过 UpdateOffset 函数修正其中包含的所有Flash 绝对地址的值，同时通过对 SCB->VTOR 赋值来将中断向量表的位置指向我们修改过内容的 RAM 地址。注意，VTOR 所指向的地址 VT_RAM_START 要按照 ARM 要求，根据中断总大小向上进行 2 的幂次对齐，例如，37 个字大小要使用 64 个字对齐。另外，中断向量表的内容，也包含有 RAM 地址，对此，我们并不需要修改。当然，UpdateOffset 函数已

经考虑到这一点，所以我们可以直接使用它。更新中断向量表以及 VTOR 的参考代码如下：

3.3.3.3. GOT

编译器已经将 C 语言中所有全局变量的地址都收集到 GOT 中，因此我们很容易对其Flash 地址的内容进行修正，参考代码如下：

4、总结

除非你仅仅是运行一小块代码，否则开发位置无关的 STM32 完整工程，不仅仅要设置正确的编译器选项，还要保证它所链接的预编译的库不含有绝对地址引用，要保证所有源代码里没有对绝对地址的硬编码，包括修改 data 区的 Flash 起始地址，中断向量表的内容与位置，以及 GOT 的内容。

问题：

该问题由某客户提出，发生在 STM32F103VDT6 器件上。据其工程师讲述：在其产品的设计中，STM32 的 HSE 外接 8MHz 的晶体产生振荡，然后通过 STM32 内部的PLL 倍频到 72MHz，作为 STM32 的系统时钟，驱动芯片工作。在 STM32 片外有专用的看门狗芯片，监控 STM32 的运行。STM32 内部的软件会在 STM32 的某个管脚上产生脉冲来复位看门狗。一旦 STM32 没有及时的产生脉冲来复位门狗，则看门狗会认为 STM32 运行不正常，从而复位 STM32。在对该产品做可靠性测试时，进行了对看门狗监控时钟失效能力的测试。测试的方法是：将 HSE 外接的晶体的两个端子接地，使其停止振荡，从而验证看门狗能否做出对 STM32 的做出复位动作。试验结果表明，看门狗没有产生复位动作。进一步测试发现，STM32 在失效情况下仍在向看门狗发送复位脉冲。

调研：

重复测试，确认其所述现象属实。检查软件代码，确认其软件没有开启 STM32 的 CSS功能。修改代码，将 PLL 的二分频从 STM32 的 MCO 管脚送出，以方便用示波器观察。通过控制晶体的管脚是否接地来控制 HSE 是否振荡。当 HSE 正常振荡时，MCO 送出的信号频率为 36MHz，当 HSE 停止振荡时，MCO 送出的信号的频率在 1.7MHz 附近，如图（一）所示:

通过调试器观察寄存器 RCC_CFGR 中的 SWS 控制控制位，其值为[10]，说明此时的系统时钟确实来自 PLL 的输出。

从 STM32F103VD 的数据手册中查找 PLL 相关的参数如表（一）：

其中，PLL 的输出频率范围是 16MHz – 72MHz。也就是说，PLL 在处于相位锁定的状态下，可以输出 16MHz – 72MHz 的时钟信号。而当输入信号频率过低而导致输出信号频率低于 16MHz 时，将可能处于失锁的状态。在这状态下，它的输出信号的频率与输入信号的频率之间，不一定符合所设定的倍频与分频关系。更确切的说，不能通过公式:

得出“输入信号频率为零时，输出信号频率也为零”这样的结论。这一点与实测的结果相吻合。

结论：

STM32 的 PLL 在没有输入信号的情况下，仍能维持在最低的频点处振荡，产生输出。以至，CPU 及其它外设仍能在 PLL 送出的时钟的驱动下运行。所以，通过判断有无时钟来驱动 CPU 执行指令的方式来判断 HSE 是否失效是行不通的。

处理：

对软件做如下修改：

1. 在软件的初始化部分，开启 STM32 的 CSS 功能；

2. 修改 NMI 中断服务程序，加入 while(1) 陷阱语句；

开启 CSS 功能后，当 HSE 失效时，STM32 会自动开启 HSI，并将系统时钟的来源切换到HSI 的输出，同时产生 NMI 中断。这样，程序的流程将停留在 NMI 中而不能产生复位片外的看门狗的脉冲。当片外看门狗溢出后，就会复位 STM32，使其恢复到正常驻的状。

建议：

STM32 中的 CSS 功能是专门为检测和处理 HSE 失效而设计的。但该功能在 STM32 复位后是被禁止的，须要软件对其使能才会发挥作用。当 CSS 单元检测到 HSE 失效时，它会使能 HSI,并将系统时钟切换到 HSI。同时，它会关闭 HSE，如果 PLL 的输入信号来自 HSE的输出，它也会关闭 PLL。CSS 单元在做时钟调整的同时，也会产生一个 NMI 中断请求，和一个送给高级定时器的刹车信号。NMI 中断请求会产生一个 NMI 中断，以便用户程序可以在中断服务程序中做紧急处理，而刹车信号则是使高级定时器进入刹车状态，以防止由其控制的电机驱动桥臂由于失去控制而过流。用户程序可以在 NMI 中断服务程序中尝试恢复 HSE 及 PLL 的功能，也可以使用陷阱让程序的流程停留在服务程序中，从而等待看门狗复位整个系统。