1. 問題描述

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

2. 問題分析及解決

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

為了使用統(tǒng)一的參考物，先建議客戶使用Cube庫(kù)下的官方示例代碼：

STM32Cube_FW_F4_V1.25.0\\Projects\\STM32F446ZE-Nucleo\\Examples\\RTC\\RTC_Calendar,此代碼剛好可以針對(duì)此問題進(jìn)行分析?？蛻羰褂么耸纠a測(cè)試問題依舊。

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

查看相關(guān)代碼：

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

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

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

Figure 1 VBAT外圍電路

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

Figure 2 VBAT波形

如上圖所示，VBAT引腳的波形，在電源掉電上電的過程中并沒有出現(xiàn)掉電的情況，也就是說，RTC擁有穩(wěn)定的電源供應(yīng)。為了避免VBAT的影響，要客戶干脆將R8這個(gè)電阻去掉再測(cè)試，結(jié)果問題依舊存在。

接下來繼續(xù)查看用戶MCU相關(guān)的原理圖，發(fā)現(xiàn)Vcap引腳上的電路與ST官方的建議并不一致：

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

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

經(jīng)驗(yàn)證，問題與這兩個(gè)電容沒有關(guān)系，當(dāng)客戶修改到2.2uF再次測(cè)試時(shí)，問題依舊。

同時(shí)注意到PDR_ON引腳，聯(lián)想到曾經(jīng)多個(gè)客戶栽到這個(gè)引腳上，客戶可能PDR_ON引腳接錯(cuò)，虛焊，懸空將會(huì)導(dǎo)致一系列奇怪問題。此引腳涉及到掉電檢測(cè)。要客戶仔細(xì)檢查此引腳是否已經(jīng)正常連接，客戶反饋確定正常。于是要客戶去掉R64這個(gè)10K上拉，直接短接到VDD再測(cè)試下。

結(jié)果發(fā)現(xiàn)問題依舊。

到目前為止，硬件上該檢查的也差不多檢查了，還是沒有找到問題的關(guān)鍵。這個(gè)時(shí)候，想起此問題是由于備份寄存器的值丟失引起，那么什么時(shí)候下會(huì)丟失呢？思來想去，無(wú)外乎以下幾種情況 ：

1> VDD和VBAT同時(shí)掉電

2> 客戶代碼意外修改

3> 檢測(cè)到入侵事件

首先排除前面兩種原因，客戶的VBAT不會(huì)掉電，第一種情況排除?？蛻羰褂玫氖荢T官方提供的示例代碼，應(yīng)該不存在意外修改的情況，那么第三種…可是示例代碼中也沒有使能入侵檢測(cè)??？

于是想到errata sheet, 打開并發(fā)現(xiàn)如下內(nèi)容 ：

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

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

其波形如下所示 ：

Figure 4 PC13引腳波形

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

Figure 5評(píng)估板上的PC13

同時(shí)評(píng)估板上的ST-Link部分的STM32F103的RTC_PC13也是外部10K下拉 ：

Figure 6 STM32F103上的PC13外部下拉

看來PC13是有講究的。于是請(qǐng)客戶將PC13引腳拉地再測(cè)試，結(jié)果問題不再出現(xiàn)?？磥泶藛栴}確實(shí)由PC13引腳引起。

為了重現(xiàn)客戶的現(xiàn)象，我在STM32F446-EVAL評(píng)估板上嘗試重現(xiàn)，但是，始終沒有重現(xiàn)，但好在客戶修改PC13引腳后確實(shí)問題得到解決，所以此問題也就到此為止。

3. 后記

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