一個關(guān)于MCU讀保護操作后程序不能運行的話題

某日，一來自北京的工程師跟我說在使用STM32L151芯片做產(chǎn)品開發(fā)，基本功能開發(fā)完畢。他欲通過用戶程序?qū)π酒�信息塊的相關(guān)選項字節(jié)進行配置，來完成芯片的讀保護。結(jié)果他發(fā)現(xiàn)無法利用其用戶程序?qū)崿F(xiàn)芯片的讀保護加密。

他把涉及芯片讀保護操作的代碼發(fā)給我，希望協(xié)助查看測試。我簡單測試了下，發(fā)現(xiàn)可以實現(xiàn)讀保加密并告知測試結(jié)果。他很快反饋說，讀保護加密的確實現(xiàn)了，但程序沒法跑了。因為忙碌，沒做進一步測試，只是讓他再檢查下代碼。

過了個周末，客戶工程師還是充滿憂傷和委屈繼續(xù)追問此事。因為我覺得即使他自己寫不來那個讀保護加密代碼也沒關(guān)系，交給其它燒錄工具來實現(xiàn)并沒啥不好或不方便�？蛇@哥們訴說他的經(jīng)理非要它用自己的代碼實現(xiàn)，不停追問結(jié)果，折騰好幾天無果。

該工程師是利用ST官方標(biāo)準(zhǔn)固件庫做的，跟我手頭上的一樣，都是STM32L1系列標(biāo)準(zhǔn)固件庫1.3.

隨便搭建了個項目，并在代碼里做讀保護代碼的編寫。編譯生成機器碼，燒錄程序進入STM32L15x所在目標(biāo)板。復(fù)位目標(biāo)板，發(fā)現(xiàn)程序真的無法運行。通過STLINK UTLITY或STVP連接目標(biāo)板，發(fā)現(xiàn)芯片的確已經(jīng)做了LEVEL 1讀保護加密。

去掉源代碼里相關(guān)讀保護的程序代碼，再次編譯、燒錄，程序運行

一切正常。當(dāng)代碼里加了讀保護代碼后程序無法正常運行，那問題一定出在那段讀保護操作的代碼上。用戶的代碼主要就下面幾句，那最有可能出問題應(yīng)該在藍色那句。該句函數(shù)調(diào)用做實質(zhì)的讀保護操作。

Rdp_Status=FLASH_OB_GetRDP(); //查詢當(dāng)前芯片讀保護狀態(tài)

if(Rdp_Status== RESET)

{

FLASH_Unlock();

FLASH_OB_Unlock();

FLASH_OB_RDPConfig(OB_RDP_Level_1);//做讀保護配置操作

FLASH_OB_Lock();

FLASH_Lock();

FLASH_OB_Launch();

}

*********************************************************************

打開上面藍色語句的函數(shù)調(diào)用，其具體函數(shù)實現(xiàn)代碼如下：

FLASH_Status FLASH_OB_RDPConfig(uint8_t OB_RDP)

{

FLASH_Status status = FLASH_COMPLETE;

uint8_t tmp1 = 0;

uint32_t tmp2 = 0;

/* Check the parameters */

assert_param(IS_OB_RDP(OB_RDP));

status = FLASH_WaitForLastOperation(FLASH_ER_PRG_TIMEOUT);

/* calculate the option byte to write */

tmp1=(uint8_t)(~(OB_RDP ));

tmp2=(uint32_t)(((uint32_t)((uint32_t)(tmp1)<<16))|((uint32_t)OB_RDP));

if(status == FLASH_COMPLETE)

{

OB->RDP = tmp2; /* program read protection level */

}

/* Wait for last operation to be completed */

status = FLASH_WaitForLastOperation(FLASH_ER_PRG_TIMEOUT);

/* Return the Read protection operation Status */

return status;

}

上面代碼應(yīng)該說也很簡單，就幾條賦值語句。目的就是給讀保護相關(guān)選項賦予適當(dāng)?shù)臄?shù)值。這里代碼有無問題就有必要結(jié)合手冊相關(guān)部分和相關(guān)定義來做解讀。不妨看看RDP操作相關(guān)部分。

每個OPTION項都是一個32位字，高16位與低16位必須成互補關(guān)系。

其中讀保護項是在上面的第一個選項字中配置的，除了 RDP和nRDP外，還有SPRMOD和nSPROMOD,他們共同組成一個完整的、可互補校驗的配置字。

結(jié)合上面的原則再過來看上面提到的讀保護配置函數(shù):

FLASH_OB_RDPConfig( uint8_t OB_RDP); 這里OB_RDP為0xBB,目的是為了實現(xiàn)LEVEL 1讀保護加密。 當(dāng)按照如下代碼換算后：

tmp1 = (uint8_t)(~(OB_RDP ));

tmp2=(uint32_t)(((uint32_t)((uint32_t)(tmp1)<<16))|((uint32_t)OB_RDP))；

OB->RDP = tmp2; /* program read protection level */

Tmp2的結(jié)果是0x004400BB,然后把它寫給RDP所在的選項字。這樣寫顯然不符合上面的約定：選項字的高16位與低16位應(yīng)該成互補關(guān)系。即使這樣強行寫進去，校驗還是會出錯。這應(yīng)該就是執(zhí)行該操作程序無法運行的原因。

將上面代碼的兩個地方簡單修改下，其它不動。

uint8_t tmp1 = 0; ==> uint16_t tmp1 = 0;

tmp1 = (uint8_t)(~(OB_RDP )); ==> tmp1 =(~((uint16_t)(OB_RDP )));

按照上面描述修改后，賦給RDP選項字的值便是0xFF4400BB.將修改過的代碼重新燒錄。斷電、復(fù)位等都不出現(xiàn)死機現(xiàn)象，程序運行正常，利用相關(guān)工具查看芯片證實已經(jīng)做了LEVEL 1級別讀保護。

看來導(dǎo)致上面問題的原因可以歸結(jié)于ST官方參考庫函數(shù)的問題，是個BUG.不過結(jié)合芯片參考手冊還是可以發(fā)現(xiàn)和調(diào)整的。后來我去ST官網(wǎng)找了下有無關(guān)于SMT32L15X系列的最新固件庫，發(fā)現(xiàn)了1.31版本，比上面提到的版本新一點，特地查看了新版本的相關(guān)函數(shù)，新版在這個地方已經(jīng)做了更正。

他們修改時跟我上面提到的有些差異，是因為考慮到做RDP調(diào)整時不要影響當(dāng)前各SECTOR讀寫保護狀態(tài)的設(shè)置。

所以在利用庫函數(shù)編程遇到某些感覺很可能非自己軟件代碼原因?qū)е翸CU功能異常時，不妨點進相關(guān)庫函數(shù)結(jié)合技術(shù)手冊仔細查看確認(rèn)下，或者找找有無更新版本的固件庫。雖說ST官方庫做得相當(dāng)不錯了，但BUG或多或少都存在。建議剛著手開發(fā)時，盡可能下載最新版本的固件庫和相關(guān)技術(shù)資料。