Atlantis <m...@w...pl> napisał(a):
> Spróbowałem nawet zerowania struktury za pomocą funkcji memset, ale to
> chyba nie to.

W takim razie nie wiem. Niemniej ciągle się kłania monitorowanie wartości
RTC. To też jest odpowiedź na poniższe dwa Twoje akapity. Bez sprawdzenia
poprawności działania RTC nie ma
co się w ogóle zajmować time.h.

> Mam jeszcze jedną hipotezę - zauważyłem, że podczas ustawiania zegara na
> początku pracy programu (kod wygenerowany przez STM32CubeMX) podawane są
> również dodatkowe opcje (np. coś związanego ze zmianą czasu) a także
> dzień tygodnia. W swojej funkcji synchronizującej czas pominąłem te
> linijki. Po powrocie do domu zobaczę, jak będzie się zachowywał
> uzupełniony kod.

Zainicjuj zgodnie z samplami.
sTime.DayLightSaving = RTC_DAYLIGHTSAVING_NONE;
sTime.StoreOperation = RTC_STOREOPERATION_RESET;
Nie zostawiaj niezainicjowanych pól w strukturach.

> Tak BTW przyszedł mi do głowy jeszcze jeden pomysł - z tego co pamiętam
> w niektórych modelach PIC32 przed zmianą ustawień zegara konieczne było
> odblokowanie tej możliwości poprze wpisanie odpowiedniej wartości do
> jednego z rejestrów. Może coś takiego ma też miejsce przynajmniej w
> niektórych STM32? W takiej sytuacji oczekiwałbym jednak, że autorzy HAL
> wzięli to pod uwagę. Może jednak trzeba to zrobić osobno?

W STM32 też tak jest i to chyba we wszystkich. Autorzy HAL jak najbardziej o
to zadbali. Obejrzyj sobie kod funkcji ustawiających datę i czas. Jest tam
wykonywane odblokowywanie rejestrów.

>> Przy okazji: zawsze używaj time_t bo nie masz gwarancji, że timestamp
>> będzie 32-bitowy. To się może zmieniać w zależności od wersji
>> kompilatora.
> Hmm... Przecież chyba właśnie na tym polega sens stosowania typów
> zmiennych w formacie *int*_t? Rozumiem, gdybym użył typu unsigned long,
> jednak uint32_t 32-bitową zmienną bez znaku? Czyżbym nie miał racji?

Oczywiście jak najbardziej masz rację, że uint32_t to typ 32-bitowy bez
znaku i masz gwarancję, że zawsze tak będzie. Natomiast mnie chodziło o typ
time_t. Napisałem kiedyś takie coś:
struct tm * t = localtime((time_t *)&seconds);
a seconds było zadeklarowane jako uint32_t
I to działało poprawnie w GCC 5.4. Natomiast w GCC 7.2 przestało,
localtime() zaczęło zwracać bzdury. Dlaczego? Bo time_t zmieniono na
64-bitowy i localtime() pobierało za pomocą wskaźnika nie tylko zmienną
seconds ale także 4 bajty leżące obok w pamięci. Gdybym od razu zadeklarował
seconds jako time_t to nie byłoby problemu przy zmianie wersji GCC. uint32_t
to był nadal uint32_t, ale time_t zmieniono z uint32_t na uint64_t. Pewnie w
Twoim kodzie nie ma takiego problemu, ale pomyślałem, że warto wspomnieć.

--
Grzegorz Niemirowski
https://www.grzegorz.net/