{"id":4269,"date":"2020-02-19T20:00:20","date_gmt":"2020-02-19T19:00:20","guid":{"rendered":"https:\/\/msalamon.pl\/?p=4269"},"modified":"2025-12-27T17:35:26","modified_gmt":"2025-12-27T16:35:26","slug":"what-is-this-date-in-the-stm32f1-rct","status":"publish","type":"post","link":"https:\/\/msalamon.pl\/en\/what-is-this-date-in-the-stm32f1-rct\/","title":{"rendered":"What is this date in the STM32F1 RCT?"},"content":{"rendered":"\n

In the previous post I started a mini-series dedicated to the built-in RTC in STM32 chips. I began with probably the most popular microcontroller SMT32F103<\/a> found among others in the cheap BluePill<\/a> board. I got to the point where after resetting the microcontroller the time was still correct, but the date started from zero.<\/p>\n\n\n\n\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

Why is the date being reset?<\/h1>\n\n\n\n

Alright, I\u2019m only resetting the MCU, so the RTC counter keeps running. So why does the time match after reset, but the date does not?<\/p>\n\n\n\n

It comes from the way ST uses the built-in RTC counter. Let me remind you that it\u2019s used in such a way that when a day rolls over, the counter is reset. It simply does not hold a complete date like it does in Linux.<\/p>\n\n\n\n

That\u2019s why the time is preserved after reset. The date is stored in an ordinary variable in RAM, which is reset when the microcontroller starts. And that is the cause of the \u201cproblem\u201d. How do we fight it?<\/p>\n\n\n\n

Let\u2019s finally use the Backup Registers!<\/h2>\n\n\n\n

I\u2019ve mentioned backup registers a few times already. Let me remind you that these are a dozen\/several dozen battery-backed registers. Additionally, clearing these registers requires a special procedure, which is not included in a normal MCU reset.<\/p>\n\n\n\n

Writing to these registers also requires unlocking. In HAL, this lock is removed by default. This is done in the HAL_RTC_MspInit<\/em> function<\/p>\n\n\n\n

HAL_PWR_EnableBkUpAccess();\n<\/pre>\n\n\n\n
Since the lock is removed, we can write to these registers. It\u2019s very simple. Just use the HAL function from the extended RTC function set.<\/p>\n\n\n\n
void HAL_RTCEx_BKUPWrite(RTC_HandleTypeDef *hrtc, uint32_t BackupRegister, uint32_t Data);<\/pre>\n\n\n\n
You pass the RTC handle, the backup register number, and the data. Unfortunately, the argument is misleading, because it points to a 32-bit variable that you can put into the register. BKP holds ONLY 16 bits.<\/strong><\/p>\n\n\n\n
By the way, these ubiquitous 32-bit arguments are a plague of HAL, which opponents use to start flame wars on electronics forums. I partly agree with them, but come on\u2014it doesn\u2019t completely eliminate HAL \ud83d\ude42<\/p>\n\n\n\n
Ok, so how do you write the current date into these registers? Since they fit 2 bytes each, and each date variable fits in one byte, two backup registers are enough to store the complete date. I made this simple function in main.<\/p>\n\n\n\n
void BackupDateToBR(void)\n{\n    HAL_RTCEx_BKUPWrite(&amp;hrtc, RTC_BKP_DR2, ((RtcDate.Date &lt;&lt; 8) | (RtcDate.Month)));\n    HAL_RTCEx_BKUPWrite(&amp;hrtc, RTC_BKP_DR3, ((RtcDate.Year &lt;&lt; 8) | (RtcDate.WeekDay)));\n}<\/pre>\n\n\n\n
I write day and month to BKP_DR2, and year and weekday to BKP_DR3. Weekday is not mandatory \u2013 it is always recalculated in ST\u2019s library.<\/p>\n\n\n\n
When should you back up the date? There\u2019s no point doing it every second. Only when the date changes.<\/p>\n\n\n\n
if(RtcDate.Date != CompareDate)\n{\n    BackupDateToBR();\n    CompareDate = RtcDate.Date;\n}<\/pre>\n\n\n\n
Restoring the date at startup<\/h2>\n\n\n\n
Now it\u2019s enough to read this data at startup and set it using the function we already know, HAL_RTC_SetDate<\/em>. Let\u2019s try it!<\/p>\n\n\n\n
In the \/* USER CODE BEGIN Check_RTC_BKUP *\/ section in the RTC initialization\u2014where last time I inserted a return so as not to set the clock with the data entered in Cube\u2014I\u2019ll add some code. I\u2019ll read the saved date from the BKP regs and set the calendar.<\/p>\n\n\n\n
\/* USER CODE BEGIN Check_RTC_BKUP *\/\nRtcDate.Date = (HAL_RTCEx_BKUPRead(&amp;hrtc, RTC_BKP_DR2) &gt;&gt; 8);\nRtcDate.Month = HAL_RTCEx_BKUPRead(&amp;hrtc, RTC_BKP_DR2);\nRtcDate.Year = (HAL_RTCEx_BKUPRead(&amp;hrtc, RTC_BKP_DR3) &gt;&gt; 8);\nRtcDate.WeekDay = HAL_RTCEx_BKUPRead(&amp;hrtc, RTC_BKP_DR3);\n\nHAL_RTC_SetDate(&amp;hrtc, &amp;RtcDate, RTC_FORMAT_BIN);\n\n\/\/\n\/\/  You have to do not let Init code to reinitialize Time and Date in RTC.\n\/\/  It's \"a bug\" in HAL widely described and complain on forums.\n\/\/  That causes every MCU restart the time and date will be same as you configured in CubeMX.\n\/\/  All you have to do is just return before init time\/date in this user section.\n\/\/\n  return;\n\/* USER CODE END Check_RTC_BKUP *\/<\/pre>\n\n\n\n
This code will cause the date to be remembered after a microcontroller reset. Success! \u2026until\u2026<\/p>\n\n\n\n
Date rollover vs. backup<\/h2>\n\n\n\n
What happens if, during battery backup power, the date rolls over? By one, two, or 20 days? Before we move on to battery backup power, let\u2019s test this by simulating such a situation in the debugger. How? By changing the values in the RTC counter, simulating a date rollover \u201cin the absence\u201d of the core.<\/p>\n\n\n\n
To change the register, start debugging and pause code execution. Now in the upper-right corner you have several sections. Go into SFRs<\/strong>. These are Special Function Registers, i.e., simplified, you can say these are peripheral registers. Expand the tree for RTC.<\/p>\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n
The three registers we care about are \u2013 CRL, CNTH and CNTL.<\/p>\n\n\n\n
CRL \u2013 this is the control register for RTC. We\u2019ll need it so that RTC allows us to write our value into the counter. This is done with bit 4, i.e., CNF.<\/p>\n\n\n\n
CNTH and CNTL \u2013 the upper and lower RTC counters. Both 16-bit. This is where RTC counts seconds.<\/p>\n\n\n\n
Now, to change the counter value you need to:<\/p>\n\n\n\n
    \n
  1. Set the CNF bit of the CRL register to 0x1<\/li>\n\n\n\n
  2. Modify the CNTH and CNTL values \u2013 in Eclipse they will \u201creturn\u201d to their values after you enter them<\/li>\n\n\n\n
  3. Clear the CNF bit of the CRL register (0x0) to latch the introduced changes in the counter.<\/li>\n<\/ol>\n\n\n\n
    By how much should we increase the RTC counter? We want to check changes by a day or a few. One day is 86400 seconds, so that\u2019s how much you need to add to the counter for each day to simulate a day change.<\/p>\n\n\n\n
    I\u2019ll add 2 days and a few seconds \u2013 I\u2019ll set the counter to 180000. CNTH = 0x2, CNTL = 0xBF20. <\/p>\n\n\n\n
    Before the change, during pause I have the date set to 17.05.2020 and the time 16:58:17 (I jumped into the future). Now I\u2019ll change the counter and reset the MCU. This is exactly the MCU power coming back while the RTC is on battery backup power.<\/p>\n\n\n\n
    What happened?<\/p>\n\n\n
    \n
    \"\"<\/a><\/figure>\n<\/div>\n\n\n
    Damn, something is wrong! The time changed, but the day was not updated. How is that possible? We remembered the date in the backup register.<\/p>\n\n\n\n
    This is where the weakness of ST\u2019s solution shows up\u2026 The problem is in the HAL_RTC_SetDate<\/em> function. Inside this function, the RTC counter is corrected, which in short consists of CUTTING OFF THE ELAPSED DAYS<\/strong>. This causes the number of elapsed days to disappear from the RTC counter and it is not transferred to the date in any way. SCANDAL!<\/p>\n\n\n\n
    This is a terrible problem, because even using backup registers we are still not able to easily control the date. There are two solutions:<\/p>\n\n\n\n
      \n
    1. Write your own RTC handling, which will be better thought out.<\/li>\n\n\n\n
    2. Do a bit of code gymnastics and recover the date without modifying ST\u2019s code (HAL and the RTC lib).<\/li>\n<\/ol>\n\n\n\n
      Let me do the second option. Just for practice and to show that you can still use the library generated by Cube.<\/p>\n\n\n\n
      Full date recovery<\/h2>\n\n\n\n
      Oh, HAL opponents will hate me, because I\u2019m going to make a workaround now involving adding many clock cycles. But maybe they\u2019ll praise me for ingenuity \ud83d\ude42 Feel free to discuss.<\/p>\n\n\n\n
      I will need two RTC_DateTypeDef<\/em> variables:<\/p>\n\n\n\n
        \n
      1. RtcDate, which I use everywhere in the later code. This is the target variable that should contain the date.<\/li>\n\n\n\n
      2. BackupDate \u2013 a temporary variable for calculations.<\/li>\n<\/ol>\n\n\n\n
        Everything will happen in RTC initialization. After MCU startup, I collect the backup registers into the target variable.<\/p>\n\n\n\n
        \/* USER CODE BEGIN Check_RTC_BKUP *\/\n\nRTC_DateTypeDef BackupDate;\n\nRtcDate.Date = (HAL_RTCEx_BKUPRead(&amp;hrtc, RTC_BKP_DR2) &gt;&gt; 8);\nRtcDate.Month = HAL_RTCEx_BKUPRead(&amp;hrtc, RTC_BKP_DR2);\nRtcDate.Year = (HAL_RTCEx_BKUPRead(&amp;hrtc, RTC_BKP_DR3) &gt;&gt; 8);\nRtcDate.WeekDay = HAL_RTCEx_BKUPRead(&amp;hrtc, RTC_BKP_DR3);<\/pre>\n\n\n\n
        In the next step I collect the time, which is correct, into the target time variable. At this moment a new date is also calculated based on the RTC counter. By adding 2 days, it will be January 3rd of year 00, because ST\u2019s software calendar counts from January 1st of year 00.<\/p>\n\n\n\n
        Now I collect that date into the temporary backup variable.<\/p>\n\n\n\n
        HAL_RTC_GetTime(&amp;hrtc, &amp;RtcTime, RTC_FORMAT_BIN); \/\/ There is also an internal date update based on HW RTC time elapsed!!\nHAL_RTC_GetDate(&amp;hrtc, &amp;BackupDate, RTC_FORMAT_BIN); \/\/ Days elapsed since MCU power down<\/pre>\n\n\n\n
        Now it\u2019s enough to add these 2 days to our target calendar variable and everything is great? Yes! Only\u2026 what if it\u2019s so many days that in the new date the month or year rolls over. The calculations become complicated\u2026<\/p>\n\n\n\n
        Operations on the number of elapsed days<\/h2>\n\n\n\n
        I found two useful algorithms<\/a> operating on integers. They do have some issues with year zero, but that can be worked around.<\/p>\n\n\n\n
        The first function, CalculateDayNumber <\/em>, is supposed to return the day number from the beginning of the calendar based on the date.<\/p>\n\n\n\n
        The second returns the date based on the day number.<\/p>\n\n\n\n
        To avoid strange errors around year zero, I added and subtracted 20 years in both functions. 20 because, like year zero, it is a leap year. So there won\u2019t be errors because of that.<\/p>\n\n\n\n
        \/* USER CODE BEGIN 1 *\/\nuint32_t CalculateDayNumber(uint8_t Date, uint8_t Month, uint8_t Year)\n{\n\t\/\/ Format:\n\t\/\/ DD.MM.YY\n\tuint32_t _Year = Year + 20;\n\tMonth = (Month + 9) % 12;\n\t_Year = _Year - (Month \/ 10);\n\treturn ((365 * _Year) + (_Year \/ 4) - (_Year \/ 100) + (_Year \/ 400) + (((Month * 306) + 5) \/ 10) + (Date - 1));\n}\n\nvoid CalculateDateFromDayNumber(uint32_t DayNumber, uint8_t *Date, uint8_t *Month, uint8_t *Year)\n{\n\tuint32_t _Date, _Month, _Year;\n\t_Year = ((10000 * DayNumber) + 14780) \/ 3652425;\n\tint32_t ddd = DayNumber - ((365 * _Year) + (_Year \/ 4) - (_Year \/ 100) + (_Year \/ 400));\n\tif (ddd &lt; 0)\n\t{\n\t\t_Year -= 1;\n\t\tddd = DayNumber - ((365 * _Year) + (_Year \/ 4) - (_Year \/ 100) + (_Year \/ 400));\n\t}\n\tint32_t mi = ((100 * ddd) + 52) \/ 3060;\n\t_Month = (mi + 2) % 12 + 1;\n\t_Year = _Year + (mi + 2)\/12;\n\t_Date = ddd - ((mi * 306) + 5)\/10 + 1;\n\t*Date = _Date;\n\t*Month = _Month;\n\t*Year = _Year - 20;\n}\n\/* USER CODE END 1 *\/<\/pre>\n\n\n\n
        Now, having the backup date and the date that elapsed while power was absent, I can calculate their corresponding day numbers.<\/p>\n\n\n\n
          uint32_t BackupDateDays = CalculateDayNumber(BackupDate.Date, BackupDate.Month, BackupDate.Year);\n  uint32_t RtcDateDays = CalculateDayNumber(RtcDate.Date, RtcDate.Month, RtcDate.Year);<\/pre>\n\n\n\n
        To the target date, it\u2019s enough to add the days that elapsed. However, you need to subtract January 1st due to the fact that inside the algorithm we are actually counting the day 20 years ahead (due to errors for year 0000).<\/p>\n\n\n\n
        RtcDateDays += (BackupDateDays - CalculateDayNumber(1, 1, 0));<\/pre>\n\n\n\n
        Now the only thing left is to transform the day number into a date using the second algorithm.<\/p>\n\n\n\n
        CalculateDateFromDayNumber(RtcDateDays, &amp;RtcDate.Date, &amp;RtcDate.Month, &amp;RtcDate.Year);<\/pre>\n\n\n\n
        Finally, write this date into the software calendar.<\/p>\n\n\n\n
        HAL_RTC_SetDate(&amp;hrtc, &amp;RtcDate, RTC_FORMAT_BIN);<\/pre>\n\n\n\n
        That\u2019s it \ud83d\ude42<\/p>\n\n\n\n
        Now the date will always (in 99%) be correct. I\u2019ll test again by entering 180000 into RTC.<\/p>\n\n\n
        \n
        \"\"<\/a><\/figure>\n<\/div>\n\n\n
        Does it always work? I won\u2019t bet my hand on it. Buuuut let\u2019s try adding\u2026 700 days, shall we?<\/p>\n\n\n\n
        19.05.20 + 700 days = 19.04.22 according to the calculator<\/a>.<\/p>\n\n\n
        \n
        \"\"<\/a><\/figure>\n<\/div>\n\n\n
        700 days * 86400 seconds = 60480000 seconds (0x39ADA00). Plus 2 hours gives 60847200 (0x39AF629) and I\u2019ll enter that value into RTC.<\/p>\n\n\n\n
        \"\"<\/a><\/figure>So what? It works!
        \"\"<\/a><\/figure>
        \"\"<\/a><\/figure><\/a><\/h2>\n\n\n\n
        Summary<\/h2>\n\n\n\n
        Using ST\u2019s library is quite a challenge. The creators of our favorite STMs pulled a nasty trick on us by delivering such a hard-to-use library. However, contrary to what the smartest guys say \u2013 it can be used.<\/p>\n\n\n\n
        Also remember that this is the case for the poorest RTC, where there is only a seconds counter. In STM32F4 there is already a hardware calendar. I will definitely test it in the next posts.<\/p>\n\n\n\n
        The article grew again. There are still two issues left. Battery backup, which is not as trivial as one might expect, and driving RTC with an external crystal, which on BluePill will also cause a few problems. That\u2019s for the next post!<\/p>\n\n\n\n
        In the meantime, I invite you to the comments section. Let me know if you liked this post and whether it makes sense to create articles like this. Every comment is valuable to me.<\/strong><\/p>\n\n\n\n
        The full project along with the library can be found as usual on my GitHub: LINK<\/span><\/a><\/p>\n\n\n\n
        If you noticed any mistake, disagree with something, would like to add something important, or simply feel you\u2019d like to discuss this topic, write a comment. Remember that the discussion should be polite and in accordance with the rules of the Polish language.<\/span><\/p>\n\n\n
        \n            \n
        \n    \n
        \n            
        \n            \n\n
        <\/div>\n        <\/div>\n            
        \n            \n\n
        <\/div>\n        <\/div>\n            
        \n            \n\n
        <\/div>\n        <\/div>\n            
        \n            \n\n
        <\/div>\n        <\/div>\n            
        \n            \n\n
        <\/div>\n        <\/div>\n    <\/div>\n    \n
        \n            
        \n            \n\n
        <\/div>\n        <\/div>\n            
        \n            \n\n
        <\/div>\n        <\/div>\n            
        \n            \n\n
        <\/div>\n        <\/div>\n            
        \n            \n\n
        <\/div>\n        <\/div>\n            
        \n            \n\n
        <\/div>\n        <\/div>\n    <\/div>\n<\/div>\n                \n\n
        \n            <\/span>\n    <\/div>\n    <\/div>\n","protected":false},"excerpt":{"rendered":"
        In the previous post I started a mini-series dedicated to the built-in RTC in STM32 chips. I began with probably the most popular microcontroller SMT32F103 found among others in the cheap BluePill board. I got to the point where after resetting the microcontroller the time was still correct, but the […]<\/p>\n","protected":false},"author":1,"featured_media":3395,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_links_to":"","_links_to_target":""},"categories":[160],"tags":[176,174,177],"class_list":["post-4269","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-stm32","tag-programming","tag-stm32","tag-stm32cubemx"],"_links":{"self":[{"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/posts\/4269","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/comments?post=4269"}],"version-history":[{"count":3,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/posts\/4269\/revisions"}],"predecessor-version":[{"id":4378,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/posts\/4269\/revisions\/4378"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/media\/3395"}],"wp:attachment":[{"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/media?parent=4269"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/categories?post=4269"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/tags?post=4269"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}