1
简介
  M% R" S4 Z- `% u4 k客户在使用STM32G474RE进行产品开发的时候，操作系统软件使用了RT-Thread 5.0，同时由于要做ClassB认证，所以在RT-Thread系统上，移植了ClassB 2-3-0版本安全库。用户程序另外一个功能是固件升级，在调试固件升级程序的过程中，发现一旦执行了ClassB的启动自检，就会出现固件升级失败。调试发现，固件升级失败的原因是写Flash的时候发现Flash状态寄存器的错误标志被置位，导致Flash写操作失败。客户根据现此象反馈ClassB的自检代码有隐患，导致Flash出错。
' M2 w: p0 L6 `) x' t本文分析了出现该错误的原因以及解决办法。
& r  i' ~2 w, h3 k( c1 U
- _; I) n  _  n9 |  S
) s8 F4 X+ y! K8 G7 Y) ?5 B2
( H; ^$ \8 U  y7 m9 X0 }" t问题描述
$ w! U5 F) `/ A2 g7 Z0 ]" S

  _& o' E: }, q/ E根据客户的问题反馈，我在NUCLEO-G474RE开发板上单独移植ClassB，通过调试，没有发现类似问题。为了复现该问题，从RT-Thread官方网站上下载了5.0版本的RT-Thread代码。RT-Thread对STM32的支持是相当友好的，代码中包含了对多数STM32开发板的支持，所以对于NUCLEO-G474RE开发板，只需要找到对应的目录，打开工程即可，如下图。

▲ 图1. RT-Thread工程目录

4 E* u" `) |. f" w+ O3 E
在上述工程下，直接添加ClassB的启动自检代码即可生成客户出现问题的软硬件环境。
移植完ClassB的启动自检代码，通过NUCLEO-G474RE开发板调试发现，当执行启动自检，跳转到主函数之后，通过查看Flash的寄存器，发现Flash状态寄存器的PGAERR，PGSERR标志被置位，如下图所示。

▲ 图2. Flash错误标志

从RM0440参考手册上关于PGAERR和PGSERR的描述可知，这两个标志位只能由硬件置起，而且是由于写Flash才会导致该错误标志被置起，而在测试的代码中，并没有Flash的写操作，由于之前有发现Keil调试器导致G0出现的Flash错误标志的问题，刚开始也怀疑Keil调试器导致类似问题，实际测试发现该问题与调试器无关。
* h% v1 @7 F' c" T7 G7 O+ A! C
/ w" X% `* A/ s2 j) F: y" ]- g
3
问题分析与解决
4 `6 `8 G$ ^3 r" Y7 E
) w% B. a7 o+ w3 u2 H
, K+ B$ ?! |( `* {结合参考手册对PGAERR以及PGSERR的描述，只能从写Flash的角度去分析问题产生的原因，最终通过单步调试，发现其中一句代码导致了该错误标志位的置起，如下图所示。
! D; U% j1 e6 }- R. T$ p

▲ 图3. 错误代码

$ L! y( e; w" [" i7 l" r/ S; Y3 K在SysTick_Handler中断服务程序中，调用了RT-Thread的函数rt_tick_increase，该函数中的变量thread为一个空指针，其地址为0x000000，在STM32G4中，该地址恰好映射为Flash的地址，从上面语句--thread->remaining_tick实际上产生了Flash写操作，所以最终导致了Flash的错误标志置位。
; ?. j; g5 |$ I! P找到该问题原因之后，反馈给客户，客户在其板子上验证了同样的现象，所以该问题与ClassB的自检代码没有关系，而是由于指针变量没有赋值，导致指针指向的地址为Flash地址，如果此时对该指针变量进行赋值操作，就会产生Flash错误标志位被置位的现象。
( L4 C* U( \- h5 q. y
8 l% T8 e- g8 F5 x
4
小结
, W4 |) E, ?& s3 L& m( I) J

2 U6 C1 S; U( y  z8 p在STM32软件开发中，不当的指针操作，尤其使用未经初始化的指针可能会引起莫名奇妙的问题，所以在使用指针变量的时候，需要注意指针地址的正确性。

& |' Z: w8 Z6 V) [