cancel
Showing results for 
Search instead for 
Did you mean: 

CubeMX SystemClock_Config is resetting my RTC due to LL_RCC_ForceBackupDomainReset

frank.zhao
Associate II

STM32CubeMX 5.6.1 , Atollic TrueStudio 9.3.0 , MCU is a STM32L053 with VDD wired to a coin cell. LSE is connected to a watch crystal.

The RTC works fine. Going into standby mode works fine. Waking up from standby mode works fine. Checking and resetting the WU flag works fine.

But the RTC does not keep the time or backup registers from the previous session when woken up.

The culprit is found in SystemClock_Config, where

LL_PWR_EnableBkUpAccess();
  LL_RCC_ForceBackupDomainReset();
  LL_RCC_ReleaseBackupDomainReset();
  LL_RCC_LSE_SetDriveCapability(LL_RCC_LSEDRIVE_LOW);
  LL_RCC_LSE_Enable();

The backup domain is reset and data from the RTC is lost.

Commenting out LL_RCC_ForceBackupDomainReset and LL_RCC_ReleaseBackupDomainReset solves this problem quickly. But, this code is auto-generated by CubeMX

I do not see a way in CubeMX to disable this unnecessary reset. How can I tell CubeMX to not generate code that calls those two functions?

Thanks

4 REPLIES 4
TDK
Guru

Doesn't look like STM32CubeMX has an option to disable this. You could implement logic to call SystemClock_Config only when not waking up from standby.

  /* USER CODE BEGIN Init */
  if (...) { // <--
  /* USER CODE END Init */
 
  /* Configure the system clock */
  SystemClock_Config();
 
  /* USER CODE BEGIN SysInit */
  } // <--
  /* USER CODE END SysInit */

Not an awesome solution, but it'll do what you want.

CubeMX code is really meant as more of a starting point. Once your program reaches a certain level of complexity, it may be hard to fit within the confines of what CubeMX allows.

If you feel a post has answered your question, please click "Accept as Solution".
frank.zhao
Associate II

I don't think that would work since standby would wreck the clock registers. But thanks for the information. I am getting close to the point where I can stop using CubeMX, all the low level stuff is getting tested now and once the tests all pass, I don't have to regenerate any more.

Jack Peacock_2
Senior III

You may be treating the symptom instead of the disease. There is a legitimate use for resetting the backup domain. Whenever the RTC source oscillator is changed from LSI to LSE (or HSE) or vice versa the backup domain must be reset to allow the RCC to make the change. This is deliberate RCC design decision so you don't accidentally reset a working LSE.

From your description the real problem may lie in how the HAL/Cube determines which RTCCLK oscillator is enabled at power up. I don't use HAL/Cube so no idea how it detects this situation, but at a guess look at the LSE and LSI status flags in the RCC on reset. I suspect the LSE is not enabled/running after a reset, which may be related to the lack of backup power.

Jack Peacock

7.1.3 RTC and backup registers reset
The RTC peripheral, RTC clock source selection (in RCC_CSR) and the backup registers
are reset only when one of the following events occurs:
• A software reset, triggered by setting the RTCRST bit in the RCC_CSR register (see
Section 7.3.21)
• Power reset (BOR/POR/PDR).

Don't worry, the LSE is safe, the battery power is literally never cut unless you yank out the battery. The wake up should not mess up LSE at all. I am doing detection for a true power-on-reset and resetting the backup domain somewhere else in the code now.