MX_RTC_Init STM32CubeMX 4.24 error

[elias eliatto]

Posted on January 31, 2018 at 13:44

Hello! I've found a bug in RTC adjustment, when I used STM32CubeMX 4.24 for STM32L0.

MX_RTC_Init does not activate RTC because of HAL_RTCEx_BKUPRead/HAL_RTCEx_BKUPWrite 'guard'. For example, 4.23 version did not wrap HAL_RTCEx_SetWakeUpTimer_IT in HAL_RTCEx_BKUPRead/HAL_RTCEx_BKUPWrite 'guard'. Please, compare the attached files.

[John Smith]

Posted on March 13, 2018 at 13:27

Hi

arietto86

‌ As I see, `if(HAL_RTCEx_BKUPRead(&hrtc, RTC_BKP_DR0) != 0x32F2){` line moved up and are called before `HAL_RTC_Init(&hrtc)` function. I think new version is better as it checks if the previous RTC data are saved correctly. This tells us that RTS battery are Ok and no need to initialize RTC again. Your RTC settings from previous MCU start will be saved. To change time you must to create custom function, may be based on MX_RTC_Init() and call it when you need to set time.

[John Smith]

Posted on March 13, 2018 at 13:54

rtc.c generate error when 'Generate peripheral initialization as a pair of '.c/.h' files' are set in Stm32CubeMx 4.0

Got error when generated RTC initialisation file rtc.c.

In Project -> Project Settings -> Code Generated

Checkbox 'Generate peripheral initialization as a pair of '.c/.h' files per peripheral' are set.

Part of rtc.c content:

...

debuggg

Expression usedDriverFlag is undefined on line 730, column 75 in ip_c.ftl.

The problematic instruction:

----------

==> ${usedDriverFlag} [on line 730, column 73 in ip_c.ftl]

in user-directive generateServiceCode [on line 1234, column 5 in ip_c.ftl]

...

Full rtc.c file are attached

For temporary fix I changed ip_c.ftl according to previous file version as shown below

templates/ip_c.ftl | 8 +-------

1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/templates/ip_c.ftl b/templates/ip_c.ftl

index 0406aa9..912c4ed 100644

--- a/templates/ip_c.ftl

+++ b/templates/ip_c.ftl

@@ -727,16 +727,10 @@ ETH_TxPacketConfig TxConfig;

[#if !ipName?contains('I2C')&& !ipName?contains('USB')] [#-- if not I2C --]

[#if initService.clock??]

[#if initService.clock!='none']

- [#if FamilyName=='STM32F1' && ipName=='RTC']debuggg ${usedDriverFlag}

- [#if usedDriverFlag?? && !usedDriverFlag?contains('LL')]

+ [#if FamilyName=='STM32F1' && ipName=='RTC']

#t#tHAL_PWR_EnableBkUpAccess();

#t#t/* Enable BKP CLK enable for backup registers */

#t#t__HAL_RCC_BKP_CLK_ENABLE();

- [#else]

- #t#tLL_PWR_EnableBkUpAccess();

- #t#t/* Enable BKP CLK enable for backup registers */

- #t#tLL_APB1_GRP1_EnableClock(LL_APB1_GRP1_PERIPH_BKP);

- [/#if]

[/#if]

#t#t/* ${ipName} clock enable */

[#list initService.clock?split(';') as clock]

Note that LL support are temporary removed.

STM32F103C8T6

Stm32CubeMx Version 4.0 STM32CubeF1 Firmware Package V1.6.0 / 17-May-2017

https://community.st.com/tags#/?tags=bug%20report

‌

https://community.st.com/tags#/?tags=cubemx%20v4.24

https://community.st.com/tags#/?tags=workaround

________________ Attachments : rtc.c.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxu8&d=%2Fa%2F0X0000000b20%2FPVuCKkpsSwU96a35JJ1PcWLvsd8YEP58jA6vCjRjhSg&asPdf=false

[Imen.D]

Posted on March 13, 2018 at 14:33

Hello

smith.john

,

The RTC error in code generation is fixed in the new CubeMX release.

Could you please update the new version ofSTM32

http://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-configurators-and-code-generators/stm32cubemx.html

and checkif this issue is fixed for you.

Best Regards,

Imen

[John Smith]

Posted on March 14, 2018 at 08:16

Hi

‌

In Stm32CubeMx 4.0 rtc.c generate error are fixed and file are generated normally.

But in rtc.c HAL_RTC_MspInit(RTC_HandleTypeDef* rtcHandle) starts to use LL functions, HAL_RTC_MspDeInit() uses HAL functions as expected.

void HAL_RTC_MspInit(RTC_HandleTypeDef* rtcHandle){ if(rtcHandle->Instance==RTC) { /* USER CODE BEGIN RTC_MspInit 0 */ /* USER CODE END RTC_MspInit 0 */ LL_PWR_EnableBkUpAccess(); /* Enable BKP CLK enable for backup registers */ LL_APB1_GRP1_EnableClock(LL_APB1_GRP1_PERIPH_BKP); /* RTC clock enable */ __HAL_RCC_RTC_ENABLE(); /* USER CODE BEGIN RTC_MspInit 1 */ /* USER CODE END RTC_MspInit 1 */ }}void HAL_RTC_MspDeInit(RTC_HandleTypeDef* rtcHandle){ if(rtcHandle->Instance==RTC) { /* USER CODE BEGIN RTC_MspDeInit 0 */ /* USER CODE END RTC_MspDeInit 0 */ /* Peripheral clock disable */ __HAL_RCC_RTC_DISABLE(); /* USER CODE BEGIN RTC_MspDeInit 1 */ /* USER CODE END RTC_MspDeInit 1 */ }} �?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

Old (before 4.0) HAL_RTC_MspInit() uses HAL

void HAL_RTC_MspInit(RTC_HandleTypeDef* rtcHandle){ if(rtcHandle->Instance==RTC) { /* USER CODE BEGIN RTC_MspInit 0 */ /* USER CODE END RTC_MspInit 0 */ HAL_PWR_EnableBkUpAccess(); /* Enable BKP CLK enable for backup registers */ __HAL_RCC_BKP_CLK_ENABLE(); /* RTC clock enable */ __HAL_RCC_RTC_ENABLE(); /* USER CODE BEGIN RTC_MspInit 1 */ /* USER CODE END RTC_MspInit 1 */ }}�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

Also CubeMx 4.0 Help -> Check for updates shows that no updates available. So I downloaded CubeMx 4.0 from ST site.

[Tadao Tomiyama]

Posted on April 25, 2018 at 10:31

Hi, Imen D.

I tried with these.

  STM32CubeMX 4.25.0

  STM32Cube FW_L4 V1.11.0

  NUCLEO-L476RG

Generated MX_RTC_Init(void) function in rtc.c is,

The problem John Smith said looks alive.

------John Smith said----------------

As I see, `if(HAL_RTCEx_BKUPRead(&hrtc, RTC_BKP_DR0) != 0x32F2){` line moved up and are called before `HAL_RTC_Init(&hrtc)` function.

--------------------------------------------

Thanks.

[Kevin Kessler]

Posted on April 26, 2018 at 01:15

I'd just like to second that this is a problem. I'm using 4.25.0, and 

STM32Cube_FW_L0_V1.10.0 and the 'Write Guard' also encompasses too much. I have a program which looks something like:

Do some stuff...

HAL_RTCEx_SetWakeUpTimer_IT(&hrtc, (

uint16_t

)counter, RTC_WAKEUPCLOCK_RTCCLK_DIV16)

HAL_PWR_EnterSTOPMode(PWR_MAINREGULATOR_ON, PWR_STOPENTRY_WFI);

Do some more stuff...

HAL_RTCEx_SetWakeUpTimer_IT(&hrtc, 5, RTC_WAKEUPCLOCK_CK_SPRE_16BITS);

HAL_PWR_EnterSTANDBYMode();

The first time through, it works. But when the uC returns from STANDBY, it does not do a HAL_RTC_Init because of the 'Write Guard', and when it enters STOP mode, it never returns. 

[Tadao Tomiyama]

Posted on April 26, 2018 at 16:04

Hi, Kevin.

Now, I am confusing.

I may misunderstood this thread's top message.

If the backup register hold value 0x32F2, RTC may have been running.

So, no re-initialization needed?

If so, your application will return from stop-mode because of RTC periodic wakeup interrupt. Now, I am confusing.

Excuse me,  this post does not solve your trouble.

Thanks

[Kevin Kessler]

Posted on April 26, 2018 at 18:07

It's very simple and reproducible. If the Write Guard prevents the HAL_RTC_Init call after the uC returns from STANDBY, the STM32 hangs in HAL_PWR_EnterSTOPMode. If the Write Guard is after the call to HAL_RTC_Init, (where it was originally) HAL_PWR_EnterSTOPMode awakens, as expected, after the RTC Clock expires.

[Nawres GHARBI]

Posted on May 02, 2018 at 12:16

hello,

will be fixed next release