cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with HAL RTC libraries

JFels
Associate

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

1 ACCEPTED SOLUTION

Accepted Solutions
Imen.D
ST Employee

Hello @JFels​ ,

Thank you for highlighting this. This issue is raised internally.

With Regards,

Imen

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen

View solution in original post

4 REPLIES 4

Good catch! @STOne-32​ @Amel NASRI​ 

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Imen.D
ST Employee

Hello @JFels​ ,

Thank you for highlighting this. This issue is raised internally.

With Regards,

Imen

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen

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

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.

 

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen