2018-08-09 03:17 PM
In the function:
HAL_RTCEx_DisableBypassShadow()
There is a cast to uint8_t in the line that resets the bit
hrtc->Instance->CR &= ((uint8_t)~RTC_CR_BYPSHAD);
This causes the upper 24 bits of this configuration register to be cleared to 0s when called. Everywhere else I looked in the HAL RTC code when resetting bits in this register it is using a (uint32_t) cast.
This was found in the library:
STM32Cube_FW_L4_V1.7.0
as well as
STM32Cube_FW_F4_V1.21.0
Solved! Go to Solution.
2018-08-14 09:35 AM
Hello @JFels ,
Thank you for highlighting this. This issue is raised internally.
With Regards,
Imen
2018-08-09 04:17 PM
Good catch! @STOne-32 @Amel NASRI
2018-08-14 09:35 AM
Hello @JFels ,
Thank you for highlighting this. This issue is raised internally.
With Regards,
Imen
2024-11-05 12:00 AM - edited 2024-11-05 12:03 AM
Dears,
I found some "strange" issues when calling these functions - after calling these functions corrupted alarms, CALIB_OUT signal. Was these issues really solved? I don't think.
Same as older report from 2015 https://community.st.com/t5/stm32-mcus-products/rtc-out-lost-when-calling-hal-rtcex-enablebypassshadow-for-hal/td-p/433472
I have looked in STM32Cube_FW_F4_V1.28.0 and still there exists this bug with conversion (uint8_t) before writing to 32 bit register:
HAL_RTCEx_DisableBypassShadow in stm32f4xx_hal_rtc_ex.c
/* Reset the BYPSHAD bit */
hrtc->Instance->CR &= (uint8_t)~RTC_CR_BYPSHAD;
Calculation example:
0xFFFFFFFF &= ~ 0x20 will produce 0x000000DF - "upper 24 bits are zeroed". But maybe I have the wrong compiler :(
I hope that it will be corrected a bit sooner.
Best Regards
Radim