W poprzednim wpisie rozpocząłem mini cykl poświęcony wbudowanemu RTC w układy STM32. Zacząłem od chyba najpopularniejszego mikrokontrolera SMT32F103 znajdującego się między innymi w taniej płytce BluePill. Dotarłem do momentu, w którym po resecie mikrokontrolera godzina nadal była prawidłowa natomiast data startowała od zera.

Dlaczego data jest zerowana?

No dobra przecież tylko resetuję MCU, więc licznik RTC biegnie dalej. Dlaczego więc godzina po resecie zgadza się natomiast data już nie?

Bierze się to z tego, w jaki sposób ST korzysta ze wbudowanego licznika RTC. Przypomnę Ci, że jest on wykorzystywany w ten sposób, że jak przekręci się dzień, to licznik jest zerowany. Po prostu nie przetrzymuje on kompletnej daty jak ma to miejsce w Linuksie.

Stąd właśnie po resecie godzina jest zachowywana. Data trzymana jest w zwykłej zmiennej w pamięci RAM, która resetowana jest po uruchomieniu mikrokontrolera. I to jest właśnie przyczyna “problemu”. Jak z tym zawalczyć?

Użyjmy w końcu Backup Registers!

Kilka razy już wspominałem o rejestrach backupowych. Przypomnę Ci, że jest to kilkanaście/kilkadziesiąt rejestrów podtrzymywanych bateryjnie. Dodatkowo zerowanie tych rejestrów wymaga specjalnej procedury, która nie jest zawarta w zwykłym resecie MCU.

Zapis do tych rejestrów również wymaga odblokowania. W HALu, blokada ta jest domyślnie zdjęta. Wykonywane jest to w funkcji HAL_RTC_MspInit

HAL_PWR_EnableBkUpAccess();

Skoro mamy zdjętą blokadę, możemy pisać do tych rejestrów. Robi się to bardzo prosto. Wystarczy użyć funkcji HALowskiej z rozszerzonej palety funkcji RTC.

void HAL_RTCEx_BKUPWrite(RTC_HandleTypeDef *hrtc, uint32_t BackupRegister, uint32_t Data);

Podajesz w niej uchwyt do RTC, numer rejestru backupowego oraz daną. Niestety tutaj jest mylący argument, ponieważ wskazuje na 32-bitową zmienną którą możesz wsadzić do rejestru. BKP mieszą TYLKO 16 bitów.

Swoją drogą te wszędobylskie 32-bitowe argumenty są plagą HALa, którą wykorzystują przeciwnicy do wszczynania zadym na forach elektronicznych. Po części się z nimi zgadzam, ale bez przesady, że to eliminuje totalnie HALa 🙂

Ok więc jak wpisać aktualną datę do tych rejestrów? Skoro mieszczą po 2 bajty, a każda ze zmiennych daty mieści się w jednym bajcie to wystarczą dwa rejestry backupowe, aby zamknąć w nich kompletną datę. Zrobiłem w mainie taką prostą funkcję.

void BackupDateToBR(void)
{
    HAL_RTCEx_BKUPWrite(&hrtc, RTC_BKP_DR2, ((RtcDate.Date << 8) | (RtcDate.Month)));
    HAL_RTCEx_BKUPWrite(&hrtc, RTC_BKP_DR3, ((RtcDate.Year << 8) | (RtcDate.WeekDay)));
}

Wpisuję do rejestru BKP_DR2 dzień i miesiąc, a do BKP_DR3 Rok i dzień tygodnia. Dzień tygodnia nie jest obowiązkowy – jest on zawsze wyliczany w bibliotece od ST na nowo.

Kiedy robić backup daty? Nie ma sensu robić tego w każdej sekundzie. Wystarczy tylko wtedy, gdy zmieni się data.

if(RtcDate.Date != CompareDate)
{
    BackupDateToBR();
    CompareDate = RtcDate.Date;
}

Odzysk daty na starcie

Teraz wystarczy odczytać te dane na starcie i nastawić ją przy pomocy znanej już nam funkcji HAL_RTC_SetDate. Spróbujmy!

W sekcji /* USER CODE BEGIN Check_RTC_BKUP */ w inizjalizacji RTC, w której ostatnio wstawiłem return, aby nie ustawiać zegara danymi wprowadzonymi w Cube dopiszę trochę kodu. Odczytam z BKP Regs zapisaną datę i ustawię kalendarz.

/* USER CODE BEGIN Check_RTC_BKUP */
RtcDate.Date = (HAL_RTCEx_BKUPRead(&hrtc, RTC_BKP_DR2) >> 8);
RtcDate.Month = HAL_RTCEx_BKUPRead(&hrtc, RTC_BKP_DR2);
RtcDate.Year = (HAL_RTCEx_BKUPRead(&hrtc, RTC_BKP_DR3) >> 8);
RtcDate.WeekDay = HAL_RTCEx_BKUPRead(&hrtc, RTC_BKP_DR3);

HAL_RTC_SetDate(&hrtc, &RtcDate, RTC_FORMAT_BIN);

//
//  You have to do not let Init code to reinitialize Time and Date in RTC.
//  It's "a bug" in HAL widely described and complain on forums.
//  That causes every MCU restart the time and date will be same as you configured in CubeMX.
//  All you have to do is just return before init time/date in this user section.
//
  return;
/* USER CODE END Check_RTC_BKUP */

Taki kod spowoduje, że po resecie mikrokontrolera data będzie pamiętana. Sukces! …do czasu…

Przeskok daty a backup

Co się stanie, jeśli w trakcie zasilania bateryjnego przeskoczy data? O jeden, dwa lub 20 dni? Zanim przejdę do zasilania bateryjnego sprawdźmy to symulując taką sytuację w debuggerze. Jak? Podmieniając wartości w liczniku RTC symulując przeskok daty pod “nieobecność” rdzenia.

W celu podmiary rejestru uruchom debug i zpauzuj wykonywanie kodu. Teraz w prawym górnym rogu masz kilka sekcji. Wejdź w SFRs. Są to Special Function Registers, czyli upraszczając to można powiedzieć, że są to rejestry peryferiów. Rozwiń drzewko dla RTC.

Interesują nas trzy rejestry – CRL, CNTH i CNTL.

CRL – jest to rejest kontrolny dla RTC. Będzie on nam potrzebny po to, aby RTC pozwoliło nam wpisać swoją wartość do licznika. Służy do tego bit nr 4, czyli CNF.

CNTH i CNTL – licznik RTC górny i dolny. Obydwa 16-bitowe. To tutaj zliczane są sekundy przez RTC.

Teraz, aby podmienić wartość w liczniku potrzebujesz:

1. Ustaw bit CNF rejestru CRL na 0x1
2. Podmień wartości CNTH i CNTL – w Eclipse “wrócą” do swoich wartości po wpisaniu
3. Skasuj bit CNF rejestru CRL (0x0), aby zatrzasnąć wprowadzone zmiany w liczniku.

O ile zwiększyć ten licznik RTC? Chcemy sprawdzić zmiany o dzień lub kilka. Jeden dzień to 86400 sekund, więc tyle dla każdego dnia musisz dodać do licznika, aby zasymulować zmianę dnia.

Dodam 2 dni i kilka sekund – ustawię licznik na 180000. CNTH = 0x2, CNTL = 0xBF20. 

Przed zmianą podczas pauzy mam ustawioną datę 17.05.2020 i godzinę 16:58:17(poleciałem w przyszłość). Teraz podmienię licznik i zresetuję MCU. To jest właśnie pojawienie się zasilania MCU przy podtrzymaniu bateryjnym na RTC.

Co się stało?

Kurde coś jest nie tak! Godzina się zmieniła, ale dzień nie został zaktualizowany. Jak to? Przecież pamiętaliśmy datę w rejestrze backupowym.

Tutaj właśnie wychodzi ułomność rozwiązania od ST… Problem tkwi w fukncji HAL_RTC_SetDate. Wewnątrz tej funkcji dokonywana jest korekta licznika RTC, która w skrócie polega na OBCIĘCIU UPŁYNIĘTYCH DNI. Powoduje to, że ilość upłyniętych dni znika z licznika RTC i nie jest w żaden sposó przenoszona na datę. SKANDAL!

To jest straszny problem, bo mimo użycia rejestrów backupowych nadal nie jesteśmy w stanie w łatwy sposób zapanować nad datą. Są dwa rozwiązania:

1. Napisać swoją obsługę RTC, która będzie lepiej przemyślana.
2. Zrobić trochę gimnastyki kodem i odzyskać datę bez modyfikacji kodu od ST(HALa i libki RTC).

Pozwól, że zrobię punkt drugi. Tak dla treningu oraz pokazania, że da się jednak skorzystać z biblioteki, którą generuje Cube.

Pełne odzyskiwanie daty

Oj przeciwnicy HALa będą mnie nienawidzieć, bo zrobię teraz workaround polegający na dodaniu wielu cykli zegara. Może jednak pochwalą mnie za pomysłowość 🙂 Zapraszam do dyskusji.

Będę potrzebował dwóch zmiennych RTC_DateTypeDef:

1. RtcDate, której używam wszędzie w późniejszym kodzie. To jest zmienna docelowa, w której ma być data.
2. BackupDate – zmienna tymczasowa do obliczeń.

Wszystko będzie się działo w inicjalizacji RTC. Po starcie MCU zbieram rejestry backupowe do zmiennej docelowej.

/* USER CODE BEGIN Check_RTC_BKUP */

RTC_DateTypeDef BackupDate;

RtcDate.Date = (HAL_RTCEx_BKUPRead(&hrtc, RTC_BKP_DR2) >> 8);
RtcDate.Month = HAL_RTCEx_BKUPRead(&hrtc, RTC_BKP_DR2);
RtcDate.Year = (HAL_RTCEx_BKUPRead(&hrtc, RTC_BKP_DR3) >> 8);
RtcDate.WeekDay = HAL_RTCEx_BKUPRead(&hrtc, RTC_BKP_DR3);

W następnym kroku zbieram czas, który jest prawidłowy do docelowej zmiennej czasu. W tym momencie obliczana jest jednocześnie nowa data na podstawie licznika RTC. Dodając 2 dni, będzie to 3 stycznia 00 roku, bo kalendarz software’owy od ST liczy od 1 stycznia 00 roku.

Teraz zbieram tę datę do tymczasowej zmiennej backupowej.

HAL_RTC_GetTime(&hrtc, &RtcTime, RTC_FORMAT_BIN); // There is also an internal date update based on HW RTC time elapsed!!
HAL_RTC_GetDate(&hrtc, &BackupDate, RTC_FORMAT_BIN); // Days elapsed since MCU power down

Teraz wystarczy dodać te 2 dni do naszej docelowej zmiennej kalendarzowej i wszystko gitara? Tak! Tylko… co jeśli będzie to tyle dni, że w nowej dacie przeskoczy miesiąc czy rok. Obliczenia robią się już skomplikowane…

Operacje na liczbie upłyniętych dni

Znalazłem dwa przydatne algorytmy działające na liczbach całkowitych. Mają ona jednak pewne problemy przy roku zerowym, ale to jest do obejścia.

Pierwsza z funkcji CalculateDayNumber ma za zadanie zwrócenie numeru dnia od początku kalendarza na podstawie daty.

Druga zwraca datę na podstawie numeru dnia.

W celu ominięcia dziwnych błędów przy roku zerowym dodałem i odjąłem 20 lat w obydwu funkcjach. 20 dlatego, że tak samo, jak rok zerowy, jest to rok przestępny. Nie będzie więc błędów z tego względu.

/* USER CODE BEGIN 1 */
uint32_t CalculateDayNumber(uint8_t Date, uint8_t Month, uint8_t Year)
{
	// Format:
	// DD.MM.YY
	uint32_t _Year = Year + 20;
	Month = (Month + 9) % 12;
	_Year = _Year - (Month / 10);
	return ((365 * _Year) + (_Year / 4) - (_Year / 100) + (_Year / 400) + (((Month * 306) + 5) / 10) + (Date - 1));
}

void CalculateDateFromDayNumber(uint32_t DayNumber, uint8_t *Date, uint8_t *Month, uint8_t *Year)
{
	uint32_t _Date, _Month, _Year;
	_Year = ((10000 * DayNumber) + 14780) / 3652425;
	int32_t ddd = DayNumber - ((365 * _Year) + (_Year / 4) - (_Year / 100) + (_Year / 400));
	if (ddd < 0)
	{
		_Year -= 1;
		ddd = DayNumber - ((365 * _Year) + (_Year / 4) - (_Year / 100) + (_Year / 400));
	}
	int32_t mi = ((100 * ddd) + 52) / 3060;
	_Month = (mi + 2) % 12 + 1;
	_Year = _Year + (mi + 2)/12;
	_Date = ddd - ((mi * 306) + 5)/10 + 1;
	*Date = _Date;
	*Month = _Month;
	*Year = _Year - 20;
}
/* USER CODE END 1 */

Teraz mając backupową datę oraz datę, która minęła podczas nieobecności zasilania mogę obliczyć odpowienio ich numery dnia.

  uint32_t BackupDateDays = CalculateDayNumber(BackupDate.Date, BackupDate.Month, BackupDate.Year);
  uint32_t RtcDateDays = CalculateDayNumber(RtcDate.Date, RtcDate.Month, RtcDate.Year);

Do docelowej daty wystarczy dodać dni, które minęły. Jednak trzeba odjąć pierwszego stycznia z uwagi na to, że wewnątrz algorytmu tak na prawdę liczymy dzień 20 lat wprzód(z uwagi na błędy dla roku 0000).

RtcDateDays += (BackupDateDays - CalculateDayNumber(1, 1, 0));

Teraz jedyne co trzeba to numer dnia przekształcić na datę przy pomocy drugiego algorytmu.

CalculateDateFromDayNumber(RtcDateDays, &RtcDate.Date, &RtcDate.Month, &RtcDate.Year);

Na koniec wpisać tę datę do kalendarza software’owego.

HAL_RTC_SetDate(&hrtc, &RtcDate, RTC_FORMAT_BIN);

To tyle 🙂

Teraz data zawsze(w 99%) będzie prawidłowa. Przetestuję ponownie wpisując 180000 do RTC.

Czy to działa zawsze? Nie dam sobie ręki uciąć. Aaaaale spróbujmy dodać… 700 dni, co?

19.05.20 + 700 dni = 19.04.22 według kalkulatora.

700 dni * 86400 sekund = 60480000 sekund (0x39ADA00). Plus 2 godziny daje 60847200 (0x39AF629) i tą wartość wpiszę do RTC.

I co? Działa!

Podsumowanie

Użycie biblioteki od ST to nie lada wyzwanie. Twórcy naszych ulubionych STMów zrobili nam niezłego psikusa dostarczając tak ciężką w użytkowaniu bibliotekę. Jednak wbrew temu, co mówią najmądrzejsi – da się jej używać.

Pamiętaj też, że tak jest dla najbiedniejszego RTC, w którym jest jedynie licznik sekund. W STM32F4 jest już sprzętowy kalendarz. Na pewno go przetestuję w kolejnych wpisach.

Artykuł znowu mi się rozrósł. Pozostały jeszcze dwie kwestie. Podtrzymanie bateryjne, które nie jest tak banalne, jak można się spodziewać oraz napędzanie RTC zewnętrznym kwarcem, który na BluePill też sprawi kilka problemów. To już w kolejnym wpisie!

Tymczasem zapraszam do sekcji komentarzy. Daj znać czy podobał Ci się ten wpis i czy jest sens robić takie artykuły. Każdy komentarz jest dla mnie cenny.

Pełny projekt wraz z biblioteką znajdziesz jak zwykle na moim GitHubie: LINK

Jeśli zauważyłeś jakiś błąd, nie zgadzasz się z czymś, chciałbyś coś dodać istotnego lub po prostu uważasz, że chciałbyś podyskutować na ten temat, napisz komentarz. Pamiętaj, że dyskusja ma być kulturalna i zgodna z zasadami języka polskiego.