STM32WL_RTC calendar won't update the time - Page 1
Forum section: electronics / beginners

author: Nikos A.
author_rank: Regular Contributor
timestamp: August 23, 2022, 08:43:12 am
content: Hi guys,I am working with the LoRaWAN_End_Node example provided in STM32WL SDK.https://github.com/STMicroelectronics/STM32CubeWL/tree/main/Projects/NUCLEO-WL55JC/Applications/LoRaWAN/LoRaWAN_End_NodeI want to set up the calendar and get the time and date. The example itself initializes the RTC in rtc.c. Then I configure the time and date and I call getTime and getDate from the main.cMy problem is that the time does not update and the seconds are always 0 as shown in the image below.However, when I create a fresh new project the calendar works fine. But when I work with the End_Node example it doesn't. I have also read the AN5406 but I didn't find any related information.https://www.st.com/resource/en/application_note/an5406-how-to-build-a-lora-application-with-stm32cubewl-stmicroelectronics.pdfAny help?rtc.c fileCode:/* USER CODE BEGIN 1 */void setTime(void) {sTime.Hours = 16;sTime.Minutes = 0;sTime.Seconds = 0;sTime.DayLightSaving = RTC_DAYLIGHTSAVING_NONE;sTime.StoreOperation = RTC_STOREOPERATION_RESET;if (HAL_RTC_SetTime(&hrtc, &sTime, RTC_FORMAT_BIN) != HAL_OK) {Error_Handler();}}void setDate(void) {sDate.WeekDay = RTC_WEEKDAY_SATURDAY;sDate.Month = RTC_MONTH_AUGUST;sDate.Date = 13;sDate.Year = 0;if (HAL_RTC_SetDate(&hrtc, &sDate, RTC_FORMAT_BIN) != HAL_OK) {Error_Handler();}}void getTime(void) {HAL_RTC_GetTime(&hrtc, &sTime, RTC_FORMAT_BIN);}void getDate(void) {HAL_RTC_GetDate(&hrtc, &sDate, RTC_FORMAT_BIN);}/* USER CODE END 1 */main.cCode:while (1) {getTime();getDate();HAL_Delay(1000);}

author: Manul
author_rank: Super Contributor
timestamp: August 23, 2022, 03:07:44 pm
content: Well, I don't know if code is correct and I don't have time to test it. But what I will say is that it is entirely possible that the compiler just "optimizes" write to the structure if you don't use it. And in your posted example it is clearly not used. Why write something which is never read later? When faced with weird behaviour it is useful to turn off all compiler optimizations. In this case you can also try declaring these structures asvolatile. Of course it might be a different problem too.

author: Nikos A.
author_rank: Regular Contributor
timestamp: August 24, 2022, 07:30:21 am
content: Thank you for your responce ManulThe code is correct since it works fine when is not integrated with the LoRaWAN_End_Node example. Also I do not believe that this is related to the compiler's optimization since as I mentioned it works fine when is not integrated with the LoRaWAN_End_Node example, but I will give it a shot.Quote from: Manul on August 23, 2022, 03:07:44 pmCould you elaborate on that? I use the sTime/sDate structures to set the time and date and then the library handles to update the variables Hours,Minutes, seconds etc. Finally I read the date and time by calling getTime and getDate.Quote from: Manul on August 23, 2022, 03:07:44 pmI believe this is the setting to disable optimization from STM32CubeIDE?

author: Manul
author_rank: Super Contributor
timestamp: August 24, 2022, 12:43:28 pm
content: Have you heard of a joke "write only memory"? Such device would conceptually be pointless. So that's why it is a joke.When I was talking about compiler optimizations, I meant that compiler tries to avoid any pointless operations. In optimizing compiler's opinion, your code:Code:while (1) {getTime();getDate();HAL_Delay(1000);}might be equivalent to:Code:while (1) {HAL_Delay(1000);}because it is pointless to get time, write to memory structure when it is never used and in fact after 1 second it is supposed to be overwritten and again never used. Compiler does not know that you attach a debugger and have intention to actually read that memory location. Note: this example is not entirely true, because low level RTC access should not be optimized out (register access) even if it is pointless, but write to structure may very well be.Your problem might be different, but I'm suggesting you first eliminate the possibility of compiler "tricks".