STM32CubeMX: RTC issues

[ingwmeier]

Posted on April 15, 2015 at 17:27

STM32F429

1) in order to use the RTC it is necessary to activate one of the options, it should be possible to just activate the RTC without any additional options.

2) the code generated by CPU sets time / date to zero, this should only be done if it has no valid contents on startup (or just the first time it is started) otherwise the time/date is lost

Regards

Werner

[arnaud239955]

Posted on April 19, 2015 at 20:38

Hi Werner,

I agree with your remark. I found a turnaround : First I select an option I don't want : Alarm A in the pinout panel for instance, then I go to the clock config panel and I select the radio button LSE, then I go back to the pinout panel to deselect the Alarm.

HTH

Regards

Zirco

[oleg239955_st]

Posted on October 06, 2015 at 08:06

Still not repaired?

I think it is needed for Cube to have checkbox for RTC:

 - Turn on (yes/no)

 - Init Date/Time (yes/no)

What a choice - or not use RTC at all, or not use CubeMX to adjust CPU configuration, or make many changes in main.c after each re-generation of code!

CubeMX developers!

If you treat CubeMX as not just a demo-maker, but as code generator that can be used by your users in entire development process, able to regenerate code while application is almost done - you should give maximum options for users!

[kevin2399]

Posted on January 19, 2016 at 19:27

I agree with Werner. I just want a settable clock from which I can get date and time.

I am using RTC_HSE, so I ended up just enabling the RTC calibration output on my F746 board.  I am using the Cube with FreeRTOS enabled for my initialization code.  However, what I am finding is that the RTC initializes OK from a cold boot, but if I try to run from the debugger or if I do a hard reset (keeping VDD up), the RTC code hangs forever in the RTC_EnterInitMode() routine, where is continually checking for the INITF bit of the RTCISR register to get set.  Furthermore, it does not time out because the HAL_GetTick() is always returning the same value.  

I've tried adding the HAL_PWR_EnableBkUpAccess() function into the HAL_RTC_MspInit routine, thinking that maybe access to thos registers isn't being allowed, but that didn't make any difference.  Has anyone else had warm boot issues with the RTC?   

[Nesrine M_O]

Posted on January 20, 2016 at 15:53

Hi,

Thanks for the suggestion! I will forward this to our team.

-Syrine-

[kevin2399]

Posted on January 20, 2016 at 17:58

There is another issue that users and ST should be aware of, and that is the inability to properly run off of HSE_RTC when using STM32CubeMX to initialize the hardware without adding user code. It will work on power-up, but not in a debugger or off of a reset.

The problem lies in SystemClock_Config, and specifically in the HAL_RCCex_PeriphCLKConfig function. In this function, a check is made to see if the RTC clock source has changed from what is already in the RCC_BDCR register. Only if it has changed will the backup domain be reset. In the case of a reset, the RCC_BDCR register will always match the RTC clock source selection auto-generated by theCube because the RTCSEL value is retained on reset. However,a reset also causes the HSE_RTC prescaler to be reset to0 (an invalid value), causing the RTC clock to not work. Therefore the RTC will never work out of reset because the prescaler is only set if the _HAL_RCC_RTC_CONFIG macro is called, and that doesn't happen due to the RTC clock source selection being unchanged. The only remedy to this that won't get wiped out when updating your Cube code is to reset the backup domain in the User Code area of HAL_MspInit as follows:

/** 
* Initializes the Global MSP. 
*/ 
void HAL_MspInit(void) 
{ 
/* USER CODE BEGIN MspInit 0 */ 
/* USER CODE END MspInit 0 */ 
HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4); 
/* System interrupt init*/ 
/* SysTick_IRQn interrupt configuration */ 
HAL_NVIC_SetPriority(SysTick_IRQn, 15, 0); 
/* USER CODE BEGIN MspInit 1 */ 
/* Enable Power Clock*/ 
__HAL_RCC_PWR_CLK_ENABLE(); 
/* Enable write access to Backup domain */ 
PWR->CR1 |= PWR_CR1_DBP; 
/* RTC Clock selection can be changed only if the Backup Domain is reset */ 
__HAL_RCC_BACKUPRESET_FORCE(); 
__HAL_RCC_BACKUPRESET_RELEASE(); 
/* USER CODE END MspInit 1 */ 
} 

I think an argument could be made that the backup domain should automatically be reset in theHAL_RCCex_PeriphCLKConfig routine if the RTC clock source is HSE_RTC and the prescaler value located in RCC_CFGR is invalid.Or, perhaps the backup domain should ALWAYS be reset in the HAL_RCCex_PeriphCLKConfig function if the clock source is HSE_RTC.After all, why else would the function be calledif not to initialize the RTC clock?

[kevin2399]

Posted on January 20, 2016 at 20:05

The Cube parameters for the predividers when HSE_RTC (1MHz) is used should be AsynchPrediv=124 and SynchPrediv=7999.  They do not set up to the proper default values if the HSE_RTC clock is selected. They set up for a 32768Hz clock.

 

[stm32cube-t]

Posted on March 29, 2016 at 18:23

Dear user,

Thank you for your report. The following requests have been logged:

- RTC enable (without any mode), only parameters relevant to HAL_RTC_Init() will be configured and generated.

- RTC Async/Sync dividers to be adjusted according to input frequency.

- RTC configuration to be called only if RTC is not already well configured at startup.

Best regards

[ttodorov]

Posted on June 21, 2016 at 00:10

Hi,

Is there any development on this?

I believe there were 2 updates of CubeMX and 1 of the STM32F4 HAL API since March 29, when this was last acknowledged by ST. Being able to add the RTC IP to the generated code by a checkbox is even more acute than represented in this thread. Please consider that even when I add it manually after the code is generated, the line which enables the RTC API stm32fxxx_hal_conf.h is commented out again, if I regenerate the project through the CubeMX utility!

Thanks,

Todor

[stm32cube-t]

Posted on October 06, 2016 at 16:10

Dear user,

Next release STM32CubeMX 4.17 shall cover one of your requests: a checkbox has been added for RTC clock source enabling.

If no mode is selected, the UI will then show only parameters relevant to RTC initialization:

 hrtc.Init.HourFormat = RTC_HOURFORMAT_24;

  hrtc.Init.AsynchPrediv = 127;

  hrtc.Init.SynchPrediv = 255;

  hrtc.Init.OutPut = RTC_OUTPUT_DISABLE;

  hrtc.Init.OutPutPolarity = RTC_OUTPUT_POLARITY_HIGH;

  hrtc.Init.OutPutType = RTC_OUTPUT_TYPE_OPENDRAIN;

Best regards