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
2024-12-10 10:06 AM
Hi @ravo,
Thank you for bringing this issue to our attention.
This issue has already been fixed for STM32L4, STM32H7 (v1.12.0), and is integrated in the next release of STM32F4.
The check and fix will be done for ALL impacted STM32 series.
Thank you again for your contribution.