实战经验 | 一个 Flash 编程错误标志的探析

客户项目中使用的 MCU 型号是 STM32G0B1, 他们反馈在代码中尝试擦除并编程 FLASH时, 发现 FLASH 的状态寄存器显示编程错误(如图 1 所示). 问题是当前代码还没有开始擦除和编程, 怎么就有了编程错误标志了呢 ? 如果不将此错误标志清除, 后续的编程操作无法继续.客户对于每次想要操作 FLASH 之前这个清除动作既感觉多余也感觉别扭, 且还不得不做, 且做了也不知对整个产品的稳定性会有什么样的影响 ?

图1.Flash 编程错误标志

访问客户时, 客户也曾私下里反馈, 经常在网络论坛上获取类似这种问题, 客户怀疑是不是STM32 本身就存在某些未曾公开的问题 ? 其实, STM32 的所有问题都已公开在勘误手册中, 如果客户的问题在勘误手册中没找到, 那么极有可能是自己代码哪里出了问题。 

问题分析及测试 

查看客户的工程, 由于客户的工程相当庞大, 各个模块和任务相互交叉, 一时半刻是很难从如此庞大的工程中找出问题, 更麻烦地是, 客户的电脑是有加密系统的, 导致在工程内查找任何字符和函数都相当痛苦. 好在是, 问题能够稳定地复现。 

于是尽量精简客户的代码, 将所有不相关的任务,模块统统移除掉, 并且保持问题能够重现. 并使其能够在 ST 官方的 NUCLEO 板上重现. 这样一来, 就完全可以脱离客户原来的硬件环境进行测试. 由于客户的环境非常不利于查找问题, 效率事倍功半. 于是, 将客户的最小化工程提取出来(与软件泄密无关), 并拿到办公室进行测试. 很快就找到了问题所在。 

原来客户的工程中有用到两个串口, 串口 2 和串口 3, 都是使用的 DMA 模式。客户不同的软件人员负责不同的模块, 最终在整合代码时, 串口 2 并没有使用, 所以串口 2 对应的初始化代码是删除掉的, 但由于串口 2 和串口 3 的 DMA 中断是共用一条中断线, 是相同的中断入口, 在中断处理时,串口 2 的 DMA 处理函数和串口 3 的处理函数都会一起处理. 问题就出在串口 2 的 DMA 中断处理并没有移除 。如 stm32g0xx_it.c 文件 :

如上图,DMA 的通道 4~7 以及 DAM2 的通道 1~5 都是共用一个中断入口的。在这个中断处理函数内, 串口 2 并没有使用到, 但其对应处理代码由于疏忽仍然保留了下来。句柄hdma_usart2_rx, 和 hdma_usart2_tx 内的数据成员很多都是不定内容或为 0. 当代码运行到函数内部, 如下图所示出问题的代码行：

如上面代码所示, 代码运行到上图 866 行代码 hdma->DmaBaseAddress->IFCR = (DMA_ISR_GIF1 << (hdma->ChannelIndex & 0x1CU));时, 实际上是给错误地址 0x0800 4109 赋值了, 此地址是内部 FLASH 地址, 这样相当于直接写 FLASH, 肯定会出错, 这也是为什么FLASH->SR.PGSERR 置位的原因. 我们都知道, 写内部 FLASH, 必须先擦除, 才可以写入, 而且写也是调用对应的 HAL API 函数, 且还需要先写 key 解锁 FLASH 等操作, 有一套写操作流程. 并不是直接用赋值语句, 这样操作出现问题一点也不奇怪。

当在中断中将串口 2 的 DMA 对应处理函数移除掉后功能就恢复正常, 这也佐证了结论的准确性。 

另外, 客户反映, 这个最小化工程, 相同的代码, 使用 IAR 时测试会出错, 但使用 KEIL 时并没有出错. 这个很奇怪. 这就引出的另外一个问题. 相同代码, 不同编译器运行结果不一致的问题。于是继续找原因, 对比 IAR 和 KEIL 的调试情况, 发现当代码运行到图 2 中 857 行代码 if 语句时其判断结果不相同. IAR 调试环境会进入到 if 语句内容, 从而导致错误的给内部 FLASH 地址赋值, 进行导致问题. 而 KEIL 调试环境并没有进入到 if 语句内部, 因此并没有触发问题. 那么为什么if 语句的判断结果不一样呢?

为了方便并避免不同编译器对长语句的执行顺序的差异, 将这个 if 长语句拆开:

如上红色代码, 用它替换原来的 if 判断语句. 结果发现 tmp1 在 IAR 和 KEIL 两个编译器环境中的值是一样的, 但是 tmp2 的值却不一样, 正是由于 tmp2 值的不一样, 导致 if 语句的最终判断结果不同。进一步发现, tmp2 的值主要是由于 flag_it 的值在两种编译器环境不一样所致。

如上 IAR 编译器环境, flag_it 的值为 0x2000 10f8。

如上 KEIL 编译器环境, flag_it 的值却是 0x2000 14F0。 

那么 flag_it 的值又是如何来的呢? 从如下代码:

如上所示, flag_it 的值来自 hdma->DmaBaseAddress->ISR, 原来是 DMA 相关 ISR 寄存器的值, 但实际调试如下:

如上 IAR 调试环境下, 出错时, hdma->DmaBaseAddress 实际指向的是地址 0, 其成员 ISR为其第一个成员, 实际也就是地址 0 上的数据. 我们都知道, 在默认情况下, MCU 的地址 0 默认是映射到内部 FLASH 的首地址 0x0800 0000 上的, 而此地址一般保存的是栈顶.。也就是说, IAR 编译环境下, 地址 0 指向栈顶地址 0x2000 10f8。 

对应地, 在 KEIL 调试环境下:

如上 KEIL 调试环境, hdma->DmaBaseAddress 同样地实际指向的是地址 0, 而地址 0 的上对应的数据为栈顶地址: 0x2000 14F0。 

也就是说, 在不同的 编译器 IAR 和 KEIL 环境下, 地址 0 指向栈顶地址是未必相同的, 进而导致两种编译环境下运行相同的代码结果不一样。 

我们知道, 通常栈地址是由编译器来指定的, 在默认情况下, IAR 和 KEIL 都会将栈放在内存的所有静态变量之后来分配. 其具体的分配地址这两个编译器都会默认按自动填充地方式来. 实际分配的地址具有不确定性, 当然, 我们也可以通过链接配置文件(IAR 的.icf 文件, KEIL 的.sct 文件)来将栈地址指定某一固定地址, 但我们通常不会这么做, 且完全没有必要.

至此，将问题稍作小结。给变量 flag_it 实际赋值栈顶地址, 不同的编译器环境下, 此栈顶地址的不一致导致变量 flag_it 的值不一致, 进而导致 if 语句的判断结果不同, 最终导致 IAR 和 KEIL 这两个编译器环境下运行相同代码而结果不一样的情形。

有时会听到某某客户反馈说, 在网络上看到 STM32 某款 MCU 存在某某问题, 然后问是不是 ST 故意隐瞒 ? 

不存在故意隐瞒的说法，芯片终究是要经过终端验证的。 

正常来讲， 任何芯片存在应用局限是正常的。对于 ST,一方面会正式地将所有已知 bug或应用局限放入到勘误手册中公示, 大家需要注意使用最新版勘误手册；另一方面,对于 ST 量产芯片，因本身缺陷导致的问题的概率非常低。事实上，绝大多数问题都来自我们自身的应用，遇到问题若简单的基于芯片品质来回猜疑非常不利于开发者静下心来查找问题原因。其实，面对问题时，我们很多人欠缺的并不是多么高深的水平，而是一颗冷静、自信并富有条理的心。