cancel
Showing results for 
Search instead for 
Did you mean: 

Cube: RTC issues still not solved

ingwmeier
Senior
Posted on September 01, 2015 at 17:06

MX_RTC_Init still overwrites RTC date and time on startup.

Cube 4.1 / F4 1.8.0

#no-cheers
8 REPLIES 8
tm3341
Associate II
Posted on September 01, 2015 at 17:51

Before you blame, make sure you did it OK!

RTC should be initialized ONLY if it does not running and times is not set. It both is OK, RTC should not be reinitialized.

All examples also works like that. Don't think CubeMX will do everything for you.

When you init RTC, save some status to RTC backup register. Before you init RTC again, check if value on RTC backup is the same as you expect. If it is not, init rtc, set clock and set variable on backup register.

ingwmeier
Senior
Posted on September 02, 2015 at 08:10

thats exactly how we solve it. We have main.c created in a different folder by cube and do a beyond compare each time we create it through cube. However I understand that the cube was intended to create a main.c where the user can add his code which is then regarded in future creations which works better and better with each version. So I don't expect Cube to do all the work, but somehow come up with a conditional hook where the user can insert his own RTC init in this example.

raptorhal2
Lead
Posted on September 02, 2015 at 16:44

In my opinion this is a short sighted implementation by ST. They overlooked the standard case where the RTC is on battery backup. They put RTC time and date setting outside of user generated code, so every time the processor is reset, so is the RTC, which defeats the purpose of battery backup.

Hal

bet
Associate II
Posted on December 09, 2016 at 16:08

Hi,

I face the same issue.

I would like to keep the cube generated code free of modifications from my side but the MX_RTC_Init function which is always called in the main (by code generated as well) always set the date and time in regards to the configuration done in cube.

And since no //USER CODE BEGIN - END blocks are available, there is no way to disable or modify the set date and time in a way that will not be erased by a new code generation from stm cube.

Did someone find a way to handle that properly?

Thanks and regards,

Bertrand

Walid FTITI_O
Senior II
Posted on December 09, 2016 at 16:27

Hi 

I submit your request internally to our CubeMX team

-Walid F-

bet
Associate II
Posted on April 07, 2017 at 14:52

Hi,

Given that several people are having this issue and that the bug is still not fixed, here is a workaround that keep your custom code on the next generation:

in main.c

/* USER CODE BEGIN PFP */
/* Private function prototypes -----------------------------------------------*/
/*override MX_RTC_Init with a custom implementation 
 that check if the rtc was already initialized*/
#define MX_RTC_Init MY_MX_RTC_Init
/* USER CODE END PFP */�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

in rtc.h or in a code section above MX_RTC_INIT prototype if you don't have the generated code splitted

/* USER CODE BEGIN Private defines */
void MY_MX_RTC_Init(void);
/* USER CODE END Private defines */�?�?�?

and in the corresponding .c file

/* USER CODE BEGIN 0 */
void MY_MX_RTC_Init(void)
{
 hrtc.Instance = RTC;
 if((hrtc.Instance->ISR & RTC_ISR_INITS) != RTC_ISR_INITS)
 {
 //first RTC init
 MX_RTC_Init();
 }
}
/* USER CODE END 0 */�?�?�?�?�?�?�?�?�?�?�?

Hope it helps.

Bertrand.

Posted on May 09, 2017 at 22:40

I used Zoyhar's code strategy and found that it did not work out-of-the-box when using the MX_RTC_init() function generated by CubeMX. The INITS flag in ISR always read 0 when re-starting the code even though the RTC was already previously initialized and happily updating the time-of-day.

The CubeMX

MX_RTC_init() 

code initializes the calendar as follows:

sDate.WeekDay = RTC_WEEKDAY_MONDAY;

sDate.Month = RTC_MONTH_JANUARY;

sDate.Date = 0x1;

sDate.Year = 0x0;

According to the Reference Manual RM0038, section 2.3.5 'RTC initialization and configuration', the setting of the INITS flag is determined by the year fields being non-zero.

After a system reset, the application can read the INITS flag in the RTC_ISR register to

check if the calendar has been initialized or not. If this flag equals 0, the calendar has not

been initialized since the year field is set at its power-on reset default value (0x00).

In summary, the generated CubeMX generated software will continue to re-initialize the RTC, and the INITS flag will not be set until the year is changed from 0x00 (e.g. year 2000 or 2100).

Posted on May 11, 2017 at 08:12

Hi Peter,

You could just check the calendar box in RTC's pinout and give a date in the configuration. That way, you will end up with non-default generated code.