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


" n, j: R3 F, j" A/ K1 N
, B, t# {( U8 k8 g
- a+ z; f* F2 A0 O% h访问客户时, 客户也曾私下里反馈, 经常在网络论坛上获取类似这种问题, 客户怀疑是不是STM32 本身就存在某些未曾公开的问题 ? 其实, STM32 的所有问题都已公开在勘误手册中, 如果客户的问题在勘误手册中没找到, 那么极有可能是自己代码哪里出了问题。
0 f" p  O. _/ d0 b: w- v& D

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

( r" b) i2 y, x5 R- }5 l" g7 Z
0 u+ y) G' M: d2 `8 D% [' q1 u于是尽量精简客户的代码, 将所有不相关的任务,模块统统移除掉, 并且保持问题能够重现. 并使其能够在 ST 官方的 NUCLEO 板上重现. 这样一来, 就完全可以脱离客户原来的硬件环境进行 LAT1210   LAT1210 - Rev 1.0 page 2/8 测试. 由于客户的环境非常不利于查找问题, 效率事倍功半. 于是, 将客户的最小化工程提取出来(与软件泄密无关), 并拿到办公室进行测试. 很快就找到了问题所在。
) z" l" H3 c+ W! A/ y3 u
; z4 Q; o) e" N
原来客户的工程中有用到两个串口, 串口 2 和串口 3, 都是使用的 DMA 模式。客户不同的软件人员负责不同的模块, 最终在整合代码时, 串口 2 并没有使用, 所以串口 2 对应的初始化代码是删除掉的, 但由于串口 2 和串口 3 的 DMA 中断是共用一条中断线, 是相同的中断入口, 在中断处理时,串口 2 的 DMA 处理函数和串口 3 的处理函数都会一起处理. 问题就出在串口 2 的 DMA 中断处理并没有移除 。如 stm32g0xx_it.c 文件 :

1. /**
   8 P+ J% B( t6 H
2. * @brief This function handles DMA1 Ch4 to Ch7, DMA2 Ch1 to Ch5 and
   5 y9 c7 m  I; U+ S4 E* Q
3. DMAMUX1 Overrun Interrupts.
   
4. */
   0 I  G1 {/ f* j# ]# H. u. }
5. void DMA1_Ch4_7_DMA2_Ch1_5_DMAMUX1_OVR_IRQHandler(void)
   . {7 o) [2 i* F2 N: T5 A4 K
6. {
   
7. /* USER CODE BEGIN
   : J- _& }2 y4 ?% ^+ v+ D' P  I# ?5 U
8. DMA1_Ch4_7_DMA2_Ch1_5_DMAMUX1_OVR_IRQn 0 */
   2 E+ |  g% b# e' i* ]+ S
9. /* USER CODE END
   9 D: _/ _; L% c# C  r; B
10. DMA1_Ch4_7_DMA2_Ch1_5_DMAMUX1_OVR_IRQn 0 */
    , \8 |% w! a4 i+ C0 S8 i  [. k
11. // HAL_DMA_IRQHandler(&hdma_spi2_tx);
    
12. // HAL_DMA_IRQHandler(&hdma_adc1);
    / h4 b/ }* X: p6 g6 ]8 z
13. HAL_DMA_IRQHandler(&hdma_usart2_rx);
    ; k1 D+ W; o) S3 _9 U
14. HAL_DMA_IRQHandler(&hdma_usart2_tx);
    ) x8 R1 M* W1 V) ^$ `. F
15. HAL_DMA_IRQHandler(&hdma_usart3_rx);
    
16. HAL_DMA_IRQHandler(&hdma_usart3_tx);
    2 `5 F3 y/ T: p( Z- {& q; c* ~% X
17. /* USER CODE BEGIN
    
18. DMA1_Ch4_7_DMA2_Ch1_5_DMAMUX1_OVR_IRQn 1 */
    
19. /* USER CODE END
    
20. DMA1_Ch4_7_DMA2_Ch1_5_DMAMUX1_OVR_IRQn 1 */
    / U2 D, y# Z" g2 G; a; L
21. }
    

复制代码

2 F0 g7 h* N; m

如上图,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 对应处理函数移除掉后功能就恢复正常, 这也佐证了结论的准确性。
+ Z% G% f6 m, p, J8 }. q3 ?另外, 客户反映, 这个最小化工程, 相同的代码, 使用 IAR 时测试会出错, 但使用 KEIL 时并没有出错. 这个很奇怪. 这就引出的另外一个问题. 相同代码, 不同编译器运行结果不一致的问题。
于是继续找原因, 对比 IAR 和 KEIL 的调试情况, 发现当代码运行到图 2 中 857 行代码 if 语句时其判断结果不相同. IAR 调试环境会进入到 if 语句内容, 从而导致错误的给内部 FLASH 地址赋值, 进行导致问题. 而 KEIL 调试环境并没有进入到 if 语句内部, 因此并没有触发问题. 那么为什么if 语句的判断结果不一样呢?
为了方便并避免不同编译器对长语句的执行顺序的差异, 将这个 if 长语句拆开:
% F) [3 W- I1 [9 b

1. /* Transfer Error Interrupt management **************************************/
   
2. // else if (((flag_it & (DMA_FLAG_TE1 << (hdma->ChannelIndex &
   . O/ T1 J6 |) K
3. 0x1CU))) != 0U) && ((source_it & DMA_IT_TE) != 0U))
   
4. else
   
5. {
   
6. 
   * x. e) a; W) m6 |
7. uint32_t tmp1, tmp2,tmp3;
   & c/ F( I+ M; n$ }, s$ K4 Z6 \
8. 
   & B4 B2 X9 z0 v9 r4 k: p
9. tmp1 =DMA_FLAG_TE1 << (hdma->ChannelIndex & 0x1CU);
   
10. tmp2 = flag_it&tmp1;
    
11. tmp3 =source_it & DMA_IT_TE;
    6 v% C4 h2 r4 [( J
12. if(tmp2 && tmp3!=0)
    - M9 X: k5 U- ~7 j
13. {
    ( z; \: E; {( [* N" H0 h- Q
14. /* When a DMA transfer error occurs */
    
15. /* A hardware clear of its EN bits is performed */
    
16. /* Disable ALL DMA IT */
    
17. __HAL_DMA_DISABLE_IT(hdma, (DMA_IT_TC | DMA_IT_HT |
    
18. DMA_IT_TE));
    . m3 Z. E( g1 F# r
19. /* Clear all flags */
    
20. #if defined(DMA2)
    
21. hdma->DmaBaseAddress->IFCR = (DMA_ISR_GIF1 <<
    1 W; N, i, v0 G3 o7 {! z2 }
22. (hdma->ChannelIndex & 0x1CU));
    
23. #else
    
24. __HAL_DMA_CLEAR_FLAG(hdma, (DMA_FLAG_GI1 <<
    
25. (hdma->ChannelIndex & 0x1CU)));
    * |5 Y8 c9 [! p3 N$ E+ w8 I2 D
26. #endif /* DMA2 */
    
27. /* Update error code */
    
28. hdma->ErrorCode = HAL_DMA_ERROR_TE;
    6 ^3 ]; B% Y% ?* ]1 L& S' w
29. /* Change the DMA state */
    " N" d' W8 `& h
30. hdma->State = HAL_DMA_STATE_READY

复制代码

8 j: g1 K1 @# ?& x
' f$ y# B, a0 [' h$ B$ x/ n如上红色代码, 用它替换原来的 if 判断语句. 结果发现 tmp1 在 IAR 和 KEIL 两个编译器环境中的值是一样的, 但是 tmp2 的值却不一样, 正是由于 tmp2 值的不一样, 导致 if 语句的最终判断结果不同。进一步发现, tmp2 的值主要是由于 flag_it 的值在两种编译器环境不一样所致。
& [; X/ v% H# L# K9 L" e$ s4 P! b" L

9 `' H7 H/ M& e4 j4 o' z3 O, c
! r7 X  E1 ?% B! A6 k7 }* c" n

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

. O* }6 k$ u6 H0 C
2 U7 z, ?. n0 I" J

: y5 Q/ j6 D# x  Q9 t
- c. x/ s2 x6 c如上 KEIL 编译器环境, flag_it 的值却是 0x2000 14F0。
那么 flag_it 的值又是如何来的呢? 从如下代码:

1. void HAL_DMA_IRQHandler(DMA_HandleTypeDef *hdma)
   
2. {
   
3. #if defined(DMA2)
   
4. uint32_t flag_it = hdma->DmaBaseAddress->ISR;
   % f* A5 |% J2 U
5. #else
   + ]0 o; H: d) u3 K- R" m
6. uint32_t flag_it = DMA1->ISR;
   
7. #endif /* DMA2 */
   % ^/ z" {% u% A, u4 L, Y5 v
8. uint32_t source_it = hdma->Instance->CCR;
   

复制代码

9 s5 j- Q( P3 d1 u. u
* v* E( M7 n' c. m' f6 H! a3 K
- H; I( [' {& J$ _: q& [2 \如上所示, flag_it 的值来自 hdma->DmaBaseAddress->ISR, 原来是 DMA 相关 ISR 寄存器的值, 但实际调试如下:


3 T: Z) g3 j" S) \3 X5 l
5 y1 K/ A" C2 p5 s: X9 v
/ P+ x$ g& ]# _  r4 T
$ Q$ z# C) [$ ^, E2 \2 j) w$ u, B如上 IAR 调试环境下, 出错时, hdma->DmaBaseAddress 实际指向的是地址 0, 其成员 ISR为其第一个成员, 实际也就是地址 0 上的数据. 我们都知道, 在默认情况下, MCU 的地址 0 默认是映射到内部 FLASH 的首地址 0x0800 0000 上的, 而此地址一般保存的是栈顶.。也就是说, IAR 编译环境下, 地址 0 指向栈顶地址 0x2000 10f8。
7 z, C+ _/ z# q2 X% i1 b" e

完整版请查看：附件 一个Flash编程错误标志的探析_v1.0.pdf (939.14 KB, 下载次数: 0)

2023-2-14 19:33 上传

点击文件名下载附件
" j0 X# p. ~  x/ i* n2 r
: Z0 b- S0 P* x; T+ O! d  _2 [) b9 R3 G