教大家輕松解決RTC意外恢復(fù)到初始值問題

關(guān)鍵詞：RTC，tamper

1. 問題描述

客戶反饋在使用STM32F446的產(chǎn)品做上電、掉電測試時，RTC會意外恢復(fù)到配置的初始值。

2. 問題分析及解決

通過與客戶郵件溝通，了解到客戶的VBAT引腳上有獨立的電池供電，在代碼中當(dāng)?shù)谝淮螁訒r會檢查備份寄存器中保留的一個標(biāo)志，如果是第一次運行，則會設(shè)置RTC的初始化，包含年月日時分秒，如果不是，則跳過，后面只讀取RTC內(nèi)的時間信息，并不再修改。

為了使用統(tǒng)一的參考物，先建議客戶使用Cube庫下的官方示例代碼：STM32Cube_FW_F4_V1.25.0ProjectsSTM32F446ZE-NucleoExamplesRTCRTC_Calendar，此代碼剛好可以針對此問題進(jìn)行分析?？蛻羰褂么耸纠a測試問題依舊。

查看示例代碼，為了排除HSE與LSE的影響，建議客戶將HSE改為HSI， LSE改為LSI，這樣一來，完全跟板上高速晶振無關(guān)，跟32.768K的低速也無關(guān)?？蛻羰褂眯薷暮蟮拇a問題依舊。 查看相關(guān)代碼：

如上面代碼所示，每次上電后會讀取BKP_DR1的值，判斷是否為第一次啟動，如果是，則配置RTC。換句話說，出現(xiàn)問題時，這個判斷肯定出現(xiàn)問題，導(dǎo)致重復(fù)配置RTC，也就是備份寄存器的值丟失！是什么原因?qū)е聜浞菁拇嫫鞯闹祦G失呢？

同時我這邊在NUCLEO板上嘗試重現(xiàn)客戶的問題，但無論如何嘗試都無法重現(xiàn)，現(xiàn)在兩邊所使用的測試軟件一模一樣，只是各自的硬件平臺有所差異，看來就是這個硬件上的差異帶來的問題。于是下一步比較客戶的硬件與NUCLEO板有何不同。

首先懷疑是VBAT引腳。要是VBAT再現(xiàn)異常，RTC重新配置就很正常，但客戶的VBAT真的會出現(xiàn)問題么？下面是客戶VBAT引腳的相關(guān)電路：

Figure 1 VBAT外圍電路 如上圖所示，客戶VBAT外部接一電池，當(dāng)VDD有電時，VDD將將電池充電，當(dāng)VDD掉電時，電池給RTC供電。于是向客戶提出VBAT的在掉電上電測試過程中的波形：

VBAT引腳的波形，在電源掉電上電的過程中并沒有出現(xiàn)掉電的情況，也就是說，RTC擁有穩(wěn)定的電源供應(yīng)。為了避免VBAT的影響，要客戶干脆將R8這個電阻去掉再測試，結(jié)果問題依舊存在。 接下來繼續(xù)查看用戶MCU相關(guān)的原理圖，發(fā)現(xiàn)Vcap引腳上的電路與ST官方的建議并不一致：

Figure 3客戶產(chǎn)品的vcap和PDR_ON引腳

如上圖所示，客戶所使用的VCAP引腳對地電容為100nF， 而ST建議的是2.2uF，這個電容涉及到MCU內(nèi)核的穩(wěn)定性，有沒有可能是MCU內(nèi)核不穩(wěn)導(dǎo)致RTC的問題呢？

經(jīng)驗證，問題與這兩個電容沒有關(guān)系，當(dāng)客戶修改到2.2uF再次測試時，問題依舊。 同時注意到PDR_ON引腳，聯(lián)想到曾經(jīng)多個客戶栽到這個引腳上，客戶可能PDR_ON引腳接錯，虛焊，懸空將會導(dǎo)致一系列奇怪問題。此引腳涉及到掉電檢測。要客戶仔細(xì)檢查此引腳是否已經(jīng)正常連接，客戶反饋確定正常。于是要客戶去掉R64這個10K上拉，直接短接到VDD再測試下。

結(jié)果發(fā)現(xiàn)問題依舊。 到目前為止，硬件上該檢查的也差不多檢查了，還是沒有找到問題的關(guān)鍵。這個時候，想起此問題是由于備份寄存器的值丟失引起，那么什么時候下會丟失呢？思來想去，無外乎以下幾種情況 ：

1》 VDD和VBAT同時掉電

2》 客戶代碼意外修改

3》 檢測到入侵事件

首先排除前面兩種原因，客戶的VBAT不會掉電，第一種情況排除?？蛻羰褂玫氖荢T官方提供的示例代碼，應(yīng)該不存在意外修改的情況，那么第三種…可是示例代碼中也沒有使能入侵檢測啊？ 于是想到errata sheet， 打開并發(fā)現(xiàn)如下內(nèi)容 ：

如上所述，即使沒有開啟入侵檢測，當(dāng)tamper引腳出現(xiàn)高電平的情況下也有可能會導(dǎo)致入侵檢測誤判。于是查看客戶的入侵檢測引腳：

從客戶的原理圖可以看出，入侵引腳PC13用戶外部按鍵輸入，有外部10K上拉電阻 ：

對照STM32F443-EVAL的相關(guān)電路 ，在評估板上，PC13用作tamper檢測但外部下拉 ：

Figure 5評估板上的PC13

同時評估板上的ST-Link部分的STM32F103的RTC_PC13也是外部10K下拉 ：

Figure 6 STM32F103上的PC13外部下拉 看來PC13是有講究的。于是請客戶將PC13引腳拉地再測試，結(jié)果問題不再出現(xiàn)?？磥泶藛栴}確實由PC13引腳引起。 為了重現(xiàn)客戶的現(xiàn)象，我在STM32F446-EVAL評估板上嘗試重現(xiàn)，但是，始終沒有重現(xiàn)，但好在客戶修改PC13引腳后確實問題得到解決，所以此問題也就到此為止。

3. 后記

很多時候當(dāng)對問題無從下手的時候，解決問題的關(guān)鍵是首先找到一個可以參考的參照物，比如軟件是有ST提供的官方示例代碼，硬件是有ST提供的NUCELO板，找到這個關(guān)鍵的參考物后接下來逐漸比較客戶的軟硬件與參照物的差異，不斷縮小范圍，這個不失為一種常規(guī)比較有效的方法，希望讀者能充分利用。

編輯：jq