stm32内部低速rtc_STM32F103使用RTC時遇到的問題

RTC出現上電後計數值變化情況

最經的一個項目要使用F103的RTC功能，為了加快項目的進度，使用了網上現有的例程，通過簡單的修改先使用着。

具體實施方法：硬體上，CR2032電池通過二極管和晶片的VBAT引腳連接配接，并使用104電容做退耦；軟體上，使用了[軟體參考]http://www.openedv.com/forum.php?mod=viewthread&tid=230238 文章中也介紹了RTC的結構原理和使用方法，重點要注意RTC的幾個點：

開啟RTC電源和時鐘。

通路RTC寄存器的使能方法，如果不使能标志位，将無法對RTC寄存器的通路。

要注意一個細節，這個需要仔細閱讀原版檔案中的時鐘同步的說明。

遇到的問題

最開始在做驅動時，直接使用了上面連結中的軟體方法，基本上照抄過來，實際使用時性能都正常，通過測試。進而後來再也沒有考慮過這個RTC功能的事情直接去做應用去了。但是直到程式末期在裝置上實際使用時才将問題暴露出來：在對整個裝置做重新上電重新開機時會出現偶然間的RTC計數器值變化大的情況5000到10000不等，也沒有任何規律。 突然間在自己腦子中開始設想N多種原因，但是解決辦法隻能回去實際測試。

log.png

原因分析和實施

原因1. 現象是在整機上電時出現時間變化的情況，懷疑是不是由于電源電路出現的幹擾導緻32768晶振工作出現波動(增加)導緻寄存器計數瞬間加快，出現的計數時間變化的情況。

根據這個原因，首先對電源電路電路做分析：由于使用的電源為DC24V電源，在PCB闆上我增加了一個TD1507的dcdc，降壓到5V在由LM1117-3.3降壓的3.3V對整個CPU系統供電。如下圖：

power.png

分析1：使用示波器測量5V和3.3V電源的紋波情況，實際得到的結果3.3V基本沒有紋波為直線型電源。5V電源有100~150khz的80mv紋波。發現了5V電源出現的紋波情況後，更改使用7805晶片做降壓，通過示波器觀察5V已經沒有紋波出現，但是依然會出現上電後RTC計時器數值變化的情況。問題并沒有得到解決。

分析2：由于出現的現象為RTC計數值偏大，是以問題分析思路依然是在上電時32768晶振工作頻率不穩定的原因。

cpu.png

由于使用的無源晶振無法使用示波器測量器輸出頻率，是以更換使用了有源晶振替代原原來無源晶振的辦法。使用外部有源晶振(JFVNY XO14NYA 32768，一款軍用的有源晶振)通過飛線和晶片管腳連接配接。測試時将示波器接入到波形輸出管腳，實時測量有源晶振的輸出波形。

結果： 問題依然存在，而且示波器顯示并沒有發現的波形頻率變化情況。再次無解。不過這個說明了問題原因并不是由于震蕩頻率變化引起的。

上傳晶片時鐘配置程式：

主程式中對時鐘的配置程式：

代碼塊

* @brief System Clock Configuration

* @retval None

*/

void SystemClock_Config(void)

{

RCC_OscInitTypeDef RCC_OscInitStruct;

RCC_ClkInitTypeDef RCC_ClkInitStruct;

RCC_PeriphCLKInitTypeDef PeriphClkInit;

//Initializes the CPU, AHB and APB busses clocks

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE|RCC_OSCILLATORTYPE_LSE;

RCC_OscInitStruct.HSEState = RCC_HSE_ON;

RCC_OscInitStruct.HSEPredivValue = RCC_HSE_PREDIV_DIV1;

RCC_OscInitStruct.LSEState = RCC_LSE_ON;

RCC_OscInitStruct.HSIState = RCC_HSI_ON;

RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;

RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;

RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL9;

if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)

{

_Error_Handler(__FILE__, __LINE__);

}

RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK

|RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;

RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;

RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;

RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV2;

RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;

if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_2) != HAL_OK)

{

_Error_Handler(__FILE__, __LINE__);

}

PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_RTC|RCC_PERIPHCLK_ADC;

PeriphClkInit.RTCClockSelection = RCC_RTCCLKSOURCE_LSE;

PeriphClkInit.AdcClockSelection = RCC_ADCPCLK2_DIV6;

if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit) != HAL_OK)

{

_Error_Handler(__FILE__, __LINE__);

}

HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);

HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);

HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);

}

思路重新回到軟體上

結合F103的資料對程式代碼重新做細緻分析，RTC的驅動程式是符合資料要做的操作流程。

分析1：晶片時鐘初始化時可能出現了對RTC寄存器計數器值的影響；

分析2：RTC被其他初始化函數影響；

修改辦法：将RTC初始化函數放置到其他驅動初始化後面。

結果：通過反複上電實驗，計數器的值保持穩定。測試基本通過，再到現場後在做定論。

結論：具體沒有想到是因為什麼原因，或者應為那個函數對RTC寄存器造成的影響。也沒有仔細做分析。希望有大神可以看到能分析出詳細的原因。歡迎評論。

附上初始化函數(以便大神幫忙分析具體原因)

init1.png

init2.png

init3.png