Skip to main content
Visitor II
January 4, 2022
Solved

Sporadic reset of Backup Domain at power off/on despite backup battery

  • January 4, 2022
  • 7 replies
  • 3831 views

Hi all,

I have the following problem: the backup domain registers are sometimes cleared on power off/on, despite having a 3V coin cell CR1632 connected to the pin VBAT and the GND plane. The RTC registers are then cleared.

The error occurs sporadic. Typically between 1 to 20 times of disconnecting/connecting the VDD supply.

Due to the missing power, I cannot debug while the bug appears.

The code was not generated using Cube or HAL libraries.

The uC used is an STM32F207IGT6 mounted on a proprietary PCB.

I already checked/tried the following:

  • Setting the BDRST bit in the RCC_BDCR register would cause a software reset of the Backup Domain. This bit is never set to 1 by the software (as far as I can tell)
  • There is a 100nF ceramic capacitor across the battery, stabilizing the voltage. The voltage seems stable, no drop or spike during turn off/turn on of VDD (measured across this 100nF capacitor).
  • Everything else works fine on the microcontroller; the RTC registers seem to be fine, I can read back the correct time and data except the the bug occurs. From that point, the time and data start counting from zero upwards...

Here is the body of the RTC function:

/******************************************************************************************************************************/
/** @brief	This function enables the RTC peripheral in the firmware (LSE clock). Furthermore it checks whether the daylight save
*						time should be active or not.
*		@param	none
*		@return none
*/
/******************************************************************************************************************************/
void startRTC(void) {
 
 RCC->APB1ENR |= RCC_APB1ENR_PWREN; // enable clock for Power interface (Other notation: APB1ENR = APB1ENR | 0x10000000, RCC_APB1ENR 0x4002384)
	PWR->CR |= PWR_CR_DBP; // enable access to RTC, BDC registers
 while ((PWR->CR & PWR_CR_DBP) == 0);										// wait for DBP = 1 (due to errata sheet)
	RCC->BDCR |= RCC_BDCR_LSEON; // enable LSE
 while ((RCC->BDCR & RCC_BDCR_LSERDY) == 0); // Wait for LSERDY = 1 (LSE is ready)
 RCC->BDCR |= (RCC_BDCR_RTCSEL_0 | RCC_BDCR_RTCEN); // set RTC clock source, enable RTC clock
 PWR->CR &= ~PWR_CR_DBP; // disable access to RTC registers	
	while ((PWR->CR & PWR_CR_DBP) != 0);										// wait for DBP = 0 (due to errata sheet)
	checkAndSetDST();
}

Has anyone had a similar problem? If yes, what was the solution?

Thanks a lot for your help,

Clara

    This topic has been closed for replies.
    Best answer by waclawek.jan

    Try to remove checkAndSetDST() function, and generally reduce the code to an absolute minimum which could be used to check if the problem is present.

    If that won't help, remove the 100nF capacitor (I'd remove it anyway, there's no benefit from it).

    If that won't help, review VCC and grounds arrangement, including the analog ones; and also NRST and PDR_ON if present. I once had problems with VDDA connection and that depleted the battery in a whim (the battery switchover is driven from the internal reset circuit). Try experimenting with a "known good" board (Nucleo, Disco, Eval).

    JW

    7 replies

    Super User
    January 4, 2022

    Try to remove checkAndSetDST() function, and generally reduce the code to an absolute minimum which could be used to check if the problem is present.

    If that won't help, remove the 100nF capacitor (I'd remove it anyway, there's no benefit from it).

    If that won't help, review VCC and grounds arrangement, including the analog ones; and also NRST and PDR_ON if present. I once had problems with VDDA connection and that depleted the battery in a whim (the battery switchover is driven from the internal reset circuit). Try experimenting with a "known good" board (Nucleo, Disco, Eval).

    JW

    Clara1Author
    Visitor II
    January 14, 2022

    Unfortunately, removing the 100nF cap wasnt a universal solution after all.

    On one PCB it solved the  RTC reset, on another PCB it aggrevated the problem to the degree where I now have a RTC reset each time I turn off/on the supply voltage.

    The battery doesnt deplete, in fact the battery can last for an eternity despite frequent switching between battery / another power supply.

    Also worth mentioning; the RTC loses time when frequently switching between battery / another power supply. I tested several (seemingly) identical PCBs with STM32F207IGT6  on them. On average, the delay was about 30 min after 5h of switching off/on with a frequency of about one cycle per 5 sec. I dont know if this problem is related to the RTC reset, but to me it seems suspicious.

    @Community member​  You mention VCC and grounds arrangement, and also NRST and PDR_ON. What exactly should I examine? That there is minimum inductance between supply and pins? Or that there is no ringing present? Or something else?

    Hope someone can point me in the right direction.

    Clara1Author
    Visitor II
    January 6, 2022

    Thank you for your speedy answer!

    I was testing different PCBs all day yesterday, all with identical layout but with different populations - some of them show the above mentioned bug, some of them dont.

    Also, I implemented the first two solutions you suggested. Removing checkAndSetDST() didnt help but removing the 100nF cap seems to do the trick. The bug didnt show after removing this cap. I have no explanation for this behaviour. But it sems to be a hardware issue.

    So without being able to understand why the bug appears, I can now fix it. Thank you so much for this hint, it saved me a ton of work and despair!

    Cheers,

    Clara

    Super User
    January 14, 2022

    > @waclawek.jan (Community Member)​ You mention VCC and grounds arrangement, and also NRST and PDR_ON. What exactly should I examine? That there is minimum inductance between supply and pins? Or that there is no ringing present? Or something else?

    Yes. :)

    I know this is of little help, but unless you have a software error (which is why I recommended to start the experimentation with cutting down the code to the bare minimum which still exhibits the problem, with no explicit backup-domain reset operation), the problem is somewhere in the powerdown/powerup sequencing. The role of NRST and PDR_ON in this regard should be clear from DS/RM; check if they are properly connected (and check physically, there may be bad solder joints for example), and review/post the NRST circuitry.

    Grounds are always the prime suspect when it comes to hardware-related issues.

    Try your code on a "known good" board such as Nucleo.

    Try experimenting with brownout settings.

    JW

    Clara1Author
    Visitor II
    January 21, 2022

    I am experimenting...

    and will get back to you with an answer when I have narrowed down this mysterious bug.

    Thanks and cheers,

    Clara

    Visitor II
    September 5, 2023

    Hi,

    Did you ever find out what was wrong?

    Asking, as we have this issue now with STM32F437

    Thanks

    Super User
    August 24, 2024

    Hi @Clara1 , @Observer_A ,

    I wonder if either of you have been able to remove the problem, and if yes, what were the conclusions.

    Thanks,

    JW

    Clara1Author
    Visitor II
    October 10, 2024

    Hi @Observer_A  and @waclawek.jan 

    Unfortunately, I never found the cause of the mysterious bug. At the end, we came to the conclusion that we have to meticulously test each PCB thouroughly before releasing it. Eventually, we found another SW workaround, which is having the RTC running on another PCB and transmitting the time periodically via a bus.

    Thank you for following up and cheers,

    Clara

    Super User
    October 10, 2024

    Hi @Clara1 ,

    Thanks for letting us know.

    Jan