01引言

& w" K" _, c' I% ], D: @/ p

在STM32的应用中，SPI算是用的比较多的外设了，也是单片机最常见外设之一。客户说它执行了关闭SPI的代码，竟然会导致Flash中的WRPERR标志置位，致使应用碰到一些问题。这就奇怪了，SPI和内部Flash看起来是风马牛不相及的事情，为什么会发生这种事呢？一起来看看吧。

. x2 {3 n4 F2 K% E1 j0 ^! K6 ?9 D

02问题

- J2 |; t4 _6 y; i. I  q

2.1 问题起源

' E6 [* l' |1 s7 B

客户在使用STM32L072RBT6的时候，使用STM32 CubeL0库，在程序编写时，发现执行关闭SPI代码时，会导致Flash的写保护错误标志WRPERR置位，导致其后面准备写EEPROM的时候，就无法对EEPROM写入了。

客户使用两个标志flag1和flag2，来观察WRPERR标志的变化。代码如图1所示。

5 J: L9 v' b$ v- S, X8 l

图1.用户测试代码

! S8 Q. }; i+ f$ u7 b5 J# W

在执行这个代码时，前面flag1还等于0，执行到flag2那句，就变成flag2等于1了，同样地取了WRPERR标志位的值。所以客户就怀疑执行_HAL_SPI_DISABLE()会把Flash的WRPERR标志置1了。

9 ?- @7 F& h0 a& q7 U; E' b1 w* P. p) W

因为在对EEPROM编程中，需要先调用位于stm32l0xx_hal_flash.c中的FLASH_WaitForLastOperation()函数，此函数中，将会对Flash所有错误标志进行检查，如果出现了错误，它则返回HAL_ERROR，导致后续对EEPROM的编程不会被执行。

' J& g; ?- C6 A( E/ H

2.2 问题重现

使用NUCLEO-L053R8来验证客户的这个问题。在\STM32Cube_FW_L0_V1.10.0\Projects\STM32L052R8-Nucleo\Examples\SPI\SPI_FullDuplex_ComPolling例程中直接进行修改测试。

5 O) g9 c2 m! ~, i/ B  ~$ q7 q- r

首先，把客户的测试代码加到例程中SPI初始化之后的位置。如图2所示。

图2.测试代码1（位于SPI初始化之后）

编译，并在线调试，发现并没有出现客户所描述的问题。如图3所示。

图3.测试代码1结果（位于SPI初始化之后）

可以看到，WRPERR的值并没有被置1，Flag1和Flag2的值也都是0。那么，为什么客户说他那边会有这个问题呢？

3 p( P* h- J1 b4 _: b

再回头仔细看一下客户的测试代码，发现客户的测试代码中并没有对SPI进行初始化，其_HAL_SPI_DISABLE()代码是放在其他外设初始化之后的。

% a. |) _5 a! w% I6 |, S9 Q

好，那么再来修改一下测试代码，把客户这三句测试代码挪动到SPI初始化之前，如图4所示。

图4.测试代码2（位于SPI初始化之前）

! y2 t  Q2 ]& Y1 h% ~. v+ ]

编译，并在线调试，这时，会惊奇地发现客户所描述地问题来了。其结果如图5所示。

图5.测试代码2结果（位于SPI初始化之前）

可以看到，这时Flash的WRPERR标志位置1了，测试代码中，flag2的值也跟flag1不同了。

再做一个实验，将此处的HAL库写法，改成直接操作寄存器，来试一下。测试代码变成是图6这样的。

0 H- o) i" O, b

图6.测试代码3（位于SPI初始化之前，直接操作寄存器）

编译，在线调试，这次又惊喜地发现，问题不见了。结果如图7所示。

图7.测试代码3结果（位于SPI初始化之前，直接操作寄存器）

" M6 Q8 J# u4 b" m# n9 s% ?' `+ C

三种操作，为什么只有第二种方式有问题呢？而且为什么错的偏偏是Flash的写保护错误标志WRPERR呢？接下来可以分析一下它们的反汇编代码，看看到底是哪里出问题了。

+ J4 `# o# i0 N, ]% h9 T4 N6 [

2.3 反汇编分析

: E, B* R! d: e2 z7 H! J

对于三种情况，把反汇编拉出来看最清楚其操作过程了。

先分析第一种情况——测试代码位于SPI初始化之后。其反汇编如图8所示。

% T; L6 g" `7 ]; J# t  }8 K9 @

图8.测试代码1的反汇编（位于SPI初始化之后）

从之前的Watch窗口，知道flag1的地址为 0x2000000c，flag2的地址为0x2000000d。

现在对三句C语言测试语句的反汇编语句进行解析，如下：

6 [# E' D0 k  u+ w

+ Q7 g6 y: m- L( s& h( x

可以看到，这段汇编是一点问题都没有的。

! v2 G2 [  e6 i5 O( ^

接下来，先分析第三种情况——也就是测试代码放在SPI初始化之前，但是使用直接操作寄存器的方式。其反汇编如图9所示。

图9.测试代码3的反汇编（位于SPI初始化之前，直接操作寄存器）

- @& k# H: N& N- m+ m+ i6 D

从之前的Watch窗口，知道flag1的地址为0x2000000c，flag2的地址为0x2000000d。

现在对三句C语言测试语句的反汇编语句进行解析，如下：

可以看到，这段汇编也是一点问题都没有的。

最后，再来分析一下有问题的第二种情况，也就是测试代码放在SPI初始化之前，但是使用_HAL_SPI_DISABLE()关闭SPI的情况。其反汇编如图10所示。

) Z0 O$ T1 _' M* D4 h8 n$ c7 d

图10.测试代码2的反汇编（位于SPI初始化之前）

: @) M7 A+ M& Y& p/ n9 E

从之前的Watch窗口，知道flag1的地址为0x20000008，flag2的地址为0x20000009。

现在对三句C语言测试语句的反汇编语句进行解析，如下：

可以看到，问题出在哪了？问题就出在“STR R3,[R 2]”这个语句上，这个语句在0x00000000这个位置写值，而0x00000000此时映射的是Flash的地址0x08000000，也就是Stack Pointer的位置。如图11和图12所示。

% s  M% j$ x) _8 R4 @

图11.0x00000000地址的数据

图12.0x08000000地址的数据

" ^0 t( ]+ h% j$ n9 l. ]$ F

首先，这个位置本来就不应该被修改。

第二，因为没有对Flash程序存储器进行解锁，就往里边写值，就会造成写保护错误，导致WRPERR标志位置位。所以，可以明白为什么WRPERR会被置位了。

可是关键的问题在哪儿呢？在执行“LDR  R2,[R0,#4]”这条语句时，R2本来应该是SPI2_CR1的地址，但是它竟然是0x00000000！如图13所示。

$ t- s- @: `' ^) {* P* A

图13.0x2000000c地址的数据

/ j1 _+ G7 D+ J, u. r

从Watch窗口来看一下SpiHandle的情况。如图14所示。

图14.SpiHandle（未初始化）

从图14可以看到，其实刚才的0x2000000c地址就是SpiHandle结构体的地址，也是SpiHandle.Instance的地址，而SpiHandle.Instance的值为0。SpiHandle.Ins tance.CR1的地址为0x0，导致显示它装载的值是Stack pointer的值0x20000468，这里本应该是SPI2_CR1的地址和SPI2_CR1的值。

也就是因为这里的问题，才会导致了后面的WRPERR错误。

2.4 代码分析

  g/ O- x1 h7 u" ~1 h- r' ~9 g$ ]

再回到代码这边来看一下，有问题的代码究竟是有什么情况。客户的代码主要就是一句关闭SPI的语句“_HAL_SPI_DISABLE(&SpiHandle);”。

. n, Z: \' S8 m

这个语句是怎么解析的？它再stm32l0xx_hal_spi.h中解析，如图15所示。

图15._HAL_SPI_DISABLE函数

7 E3 w  S8 g3 n2 _) B! }$ r' d1 R+ Q

看到这个函数时，看到了重要的字眼——“Instance”！就明白是什么问题了，因为这个SpiHandle.Instance还没有被初始化呢！这也说明了为什么在图14中，看到的SpiHandle.Instance的值为0x0，而SpiHandle.Instance. CR2的值为0x20000468。关键就在于这个SpiHandle. Instance还没有初始化。

所以，把客户的测试代码放在SPI初始化代码之后没有问题，就是因为这个SpiHandle.Instance已经被初始化过了。所以，它不会有问题。

4 E  M/ n' a7 }+ {7 m3 H

03问题解决

本来客户的代码就没有必要这么写，因为SPI都没初始化，对它进行关闭并没有什么意义。

如果非要在这里关闭SPI的话，那就要先对SpiHandle.Instance进行初始化才行。如图16所示。

6 T+ c9 f* d- o: g, x% U

图16._HAL_SPI_DISABLE函数

加了“SpiHandle.Instance=SPIx;”初始化后，再跑这段代码，就不会出现客户所说的问题了。

现在再来看一下SpiHandle的情况。

1 N, ?9 f! b, X: d2 |

图17.SpiHandle（SpiHandle.Instance已初始化）

  \6 g7 J5 l: K$ n& I/ b$ P) Q

经过对SpiHandle.Instance的初始化，这里就可以看到SpiHandle.Instance的值为0x40003800了，为SPI2外设寄存器的基地址，而且可以看到SpiHandle.Instance. CR1的地址就是SPI2_CR1的地址0x40003800，值也是SPI2_CR1的值0x0了。

2 I1 _3 B7 W. u" _  W$ A. P

04小结

在用户代码中，SpiHandle只是定义了SPI_HandleTypeDef结构体，其各种参数并还没有进行实际初始化。在没有初始化的前提下，对其进行操作时不对的，也是危险的，应该在写代码的时候引起重视。

使用HAL库的时候，如果要对一个外设进行任何的操作，请务必记得它是被初始化过的。否则，出了问题可能都不一定知道。

- I9 o& p1 |- m7 A( A

转载自： STM32单片机

如有侵权请联系删除

5 E; S$ _# l" E3 S4 t7 N