關(guān)鍵字：SPI，F(xiàn)lash，WRPERR

目錄預(yù)覽

1 引言2 問(wèn)題3 問(wèn)題解決4 小結(jié)

01 引言

在STM32的應(yīng)用中，SPI算是用的比較多的外設(shè)了，也是單片機(jī)最常見(jiàn)外設(shè)之一。客戶說(shuō)它執(zhí)行了關(guān)閉SPI的代碼，竟然會(huì)導(dǎo)致Flash中的WRPERR標(biāo)志置位，致使應(yīng)用碰到一些問(wèn)題。這就奇怪了，SPI和內(nèi)部Flash看起來(lái)是風(fēng)馬牛不相及的事情，為什么會(huì)發(fā)生這種事呢？一起來(lái)看看吧。

02 問(wèn)題

2.1 問(wèn)題起源

客戶在使用STM32L072RBT6的時(shí)候，使用STM32 CubeL0庫(kù)，在程序編寫時(shí)，發(fā)現(xiàn)執(zhí)行關(guān)閉SPI代碼時(shí)，會(huì)導(dǎo)致Flash的寫保護(hù)錯(cuò)誤標(biāo)志W(wǎng)RPERR置位，導(dǎo)致其后面準(zhǔn)備寫EEPROM的時(shí)候，就無(wú)法對(duì)EEPROM寫入了。

客戶使用兩個(gè)標(biāo)志flag1和flag2，來(lái)觀察WRPERR標(biāo)志的變化。代碼如圖1所示。

圖1.用戶測(cè)試代碼

在執(zhí)行這個(gè)代碼時(shí)，前面flag1還等于0，執(zhí)行到flag2那句，就變成flag2等于1了，同樣地取了WRPERR標(biāo)志位的值。所以客戶就懷疑執(zhí)行_HAL_SPI_DISABLE()會(huì)把Flash的WRPERR標(biāo)志置1了。

因?yàn)樵趯?duì)EEPROM編程中，需要先調(diào)用位于stm32l0xx_hal_flash.c中的FLASH_WaitForLastOperation()函數(shù)，此函數(shù)中，將會(huì)對(duì)Flash所有錯(cuò)誤標(biāo)志進(jìn)行檢查，如果出現(xiàn)了錯(cuò)誤，它則返回HAL_ERROR，導(dǎo)致后續(xù)對(duì)EEPROM的編程不會(huì)被執(zhí)行。

2.2 問(wèn)題重現(xiàn)

使用NUCLEO-L053R8來(lái)驗(yàn)證客戶的這個(gè)問(wèn)題。在STM32Cube_FW_L0_V1.10.0ProjectsSTM32L052R8-NucleoExamplesSPISPI_FullDuplex_ComPolling例程中直接進(jìn)行修改測(cè)試。

首先，把客戶的測(cè)試代碼加到例程中SPI初始化之后的位置。如圖2所示。

圖2.測(cè)試代碼1（位于SPI初始化之后）

編譯，并在線調(diào)試，發(fā)現(xiàn)并沒(méi)有出現(xiàn)客戶所描述的問(wèn)題。如圖3所示。

圖3.測(cè)試代碼1結(jié)果（位于SPI初始化之后）

可以看到，WRPERR的值并沒(méi)有被置1，F(xiàn)lag1和Flag2的值也都是0。那么，為什么客戶說(shuō)他那邊會(huì)有這個(gè)問(wèn)題呢？

再回頭仔細(xì)看一下客戶的測(cè)試代碼，發(fā)現(xiàn)客戶的測(cè)試代碼中并沒(méi)有對(duì)SPI進(jìn)行初始化，其_HAL_SPI_DISABLE()代碼是放在其他外設(shè)初始化之后的。

好，那么再來(lái)修改一下測(cè)試代碼，把客戶這三句測(cè)試代碼挪動(dòng)到SPI初始化之前，如圖4所示。

圖4.測(cè)試代碼2（位于SPI初始化之前）

編譯，并在線調(diào)試，這時(shí)，會(huì)驚奇地發(fā)現(xiàn)客戶所描述地問(wèn)題來(lái)了。其結(jié)果如圖5所示。

圖5.測(cè)試代碼2結(jié)果（位于SPI初始化之前）

可以看到，這時(shí)Flash的WRPERR標(biāo)志位置1了，測(cè)試代碼中，flag2的值也跟flag1不同了。

再做一個(gè)實(shí)驗(yàn)，將此處的HAL庫(kù)寫法，改成直接操作寄存器，來(lái)試一下。測(cè)試代碼變成是圖6這樣的。

圖6.測(cè)試代碼3（位于SPI初始化之前，直接操作寄存器）

編譯，在線調(diào)試，這次又驚喜地發(fā)現(xiàn)，問(wèn)題不見(jiàn)了。結(jié)果如圖7所示。

圖7.測(cè)試代碼3結(jié)果（位于SPI初始化之前，直接操作寄存器）

三種操作，為什么只有第二種方式有問(wèn)題呢？而且為什么錯(cuò)的偏偏是Flash的寫保護(hù)錯(cuò)誤標(biāo)志W(wǎng)RPERR呢？接下來(lái)可以分析一下它們的反匯編代碼，看看到底是哪里出問(wèn)題了。

2.3 反匯編分析

對(duì)于三種情況，把反匯編拉出來(lái)看最清楚其操作過(guò)程了。

先分析第一種情況——測(cè)試代碼位于SPI初始化之后。其反匯編如圖8所示。

圖8.測(cè)試代碼1的反匯編（位于SPI初始化之后）

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

現(xiàn)在對(duì)三句C語(yǔ)言測(cè)試語(yǔ)句的反匯編語(yǔ)句進(jìn)行解析，如下：

可以看到，這段匯編是一點(diǎn)問(wèn)題都沒(méi)有的。

接下來(lái)，先分析第三種情況——也就是測(cè)試代碼放在SPI初始化之前，但是使用直接操作寄存器的方式。其反匯編如圖9所示。

圖9.測(cè)試代碼3的反匯編（位于SPI初始化之前，直接操作寄存器）

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

現(xiàn)在對(duì)三句C語(yǔ)言測(cè)試語(yǔ)句的反匯編語(yǔ)句進(jìn)行解析，如下：

可以看到，這段匯編也是一點(diǎn)問(wèn)題都沒(méi)有的。

最后，再來(lái)分析一下有問(wèn)題的第二種情況，也就是測(cè)試代碼放在SPI初始化之前，但是使用_HAL_SPI_DISABLE()關(guān)閉SPI的情況。其反匯編如圖10所示。

圖10.測(cè)試代碼2的反匯編（位于SPI初始化之前）

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

現(xiàn)在對(duì)三句C語(yǔ)言測(cè)試語(yǔ)句的反匯編語(yǔ)句進(jìn)行解析，如下：

可以看到，問(wèn)題出在哪了？問(wèn)題就出在“STR R3,[R 2]”這個(gè)語(yǔ)句上，這個(gè)語(yǔ)句在0x00000000這個(gè)位置寫值，而0x00000000此時(shí)映射的是Flash的地址0x08000000，也就是Stack Pointer的位置。如圖11和圖12所示。

圖11.0x00000000地址的數(shù)據(jù)

圖12.0x08000000地址的數(shù)據(jù)

首先，這個(gè)位置本來(lái)就不應(yīng)該被修改。

第二，因?yàn)闆](méi)有對(duì)Flash程序存儲(chǔ)器進(jìn)行解鎖，就往里邊寫值，就會(huì)造成寫保護(hù)錯(cuò)誤，導(dǎo)致WRPERR標(biāo)志位置位。所以，可以明白為什么WRPERR會(huì)被置位了。

可是關(guān)鍵的問(wèn)題在哪兒呢？在執(zhí)行“LDR R2,[R0,#4]”這條語(yǔ)句時(shí)，R2本來(lái)應(yīng)該是SPI2_CR1的地址，但是它竟然是0x00000000！如圖13所示。

圖13.0x2000000c地址的數(shù)據(jù)

從Watch窗口來(lái)看一下SpiHandle的情況。如圖14所示。

圖14.SpiHandle（未初始化）

從圖14可以看到，其實(shí)剛才的0x2000000c地址就是SpiHandle結(jié)構(gòu)體的地址，也是SpiHandle.Instance的地址，而SpiHandle.Instance的值為0。SpiHandle.Ins tance.CR1的地址為0x0，導(dǎo)致顯示它裝載的值是Stack pointer的值0x20000468，這里本應(yīng)該是SPI2_CR1的地址和SPI2_CR1的值。

也就是因?yàn)檫@里的問(wèn)題，才會(huì)導(dǎo)致了后面的WRPERR錯(cuò)誤。

2.4 代碼分析

再回到代碼這邊來(lái)看一下，有問(wèn)題的代碼究竟是有什么情況。客戶的代碼主要就是一句關(guān)閉SPI的語(yǔ)句“_HAL_SPI_DISABLE(&SpiHandle);”。

這個(gè)語(yǔ)句是怎么解析的？它再stm32l0xx_hal_spi.h中解析，如圖15所示。

圖15._HAL_SPI_DISABLE函數(shù)

看到這個(gè)函數(shù)時(shí)，看到了重要的字眼——“Instance”！就明白是什么問(wèn)題了，因?yàn)檫@個(gè)SpiHandle.Instance還沒(méi)有被初始化呢！這也說(shuō)明了為什么在圖14中，看到的SpiHandle.Instance的值為0x0，而SpiHandle.Instance. CR2的值為0x20000468。關(guān)鍵就在于這個(gè)SpiHandle. Instance還沒(méi)有初始化。

所以，把客戶的測(cè)試代碼放在SPI初始化代碼之后沒(méi)有問(wèn)題，就是因?yàn)檫@個(gè)SpiHandle.Instance已經(jīng)被初始化過(guò)了。所以，它不會(huì)有問(wèn)題。

03 問(wèn)題解決

本來(lái)客戶的代碼就沒(méi)有必要這么寫，因?yàn)镾PI都沒(méi)初始化，對(duì)它進(jìn)行關(guān)閉并沒(méi)有什么意義。

如果非要在這里關(guān)閉SPI的話，那就要先對(duì)SpiHandle.Instance進(jìn)行初始化才行。如圖16所示。

圖16._HAL_SPI_DISABLE函數(shù)

加了“SpiHandle.Instance=SPIx;”初始化后，再跑這段代碼，就不會(huì)出現(xiàn)客戶所說(shuō)的問(wèn)題了。

現(xiàn)在再來(lái)看一下SpiHandle的情況。

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

經(jīng)過(guò)對(duì)SpiHandle.Instance的初始化，這里就可以看到SpiHandle.Instance的值為0x40003800了，為SPI2外設(shè)寄存器的基地址，而且可以看到SpiHandle.Instance. CR1的地址就是SPI2_CR1的地址0x40003800，值也是SPI2_CR1的值0x0了。

04 小結(jié)

在用戶代碼中，SpiHandle只是定義了SPI_HandleTypeDef結(jié)構(gòu)體，其各種參數(shù)并還沒(méi)有進(jìn)行實(shí)際初始化。在沒(méi)有初始化的前提下，對(duì)其進(jìn)行操作時(shí)不對(duì)的，也是危險(xiǎn)的，應(yīng)該在寫代碼的時(shí)候引起重視。

使用HAL庫(kù)的時(shí)候，如果要對(duì)一個(gè)外設(shè)進(jìn)行任何的操作，請(qǐng)務(wù)必記得它是被初始化過(guò)的。否則，出了問(wèn)題可能都不一定知道。

完整內(nèi)容請(qǐng)點(diǎn)擊“閱讀原文”下載原文檔。

長(zhǎng)按掃碼關(guān)注公眾號(hào)

更多資訊，盡在STM32

▽點(diǎn)擊“閱讀原文”，可下載原文檔