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

[Clara1]

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

[waclawek.jan · Accepted solution]

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

[Clara1]

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

[Clara1]

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.

[waclawek.jan]

> @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

[Clara1]

I am experimenting...

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

Thanks and cheers,

Clara

[Observer_A]

Hi,

Did you ever find out what was wrong?

Asking, as we have this issue now with STM32F437

Thanks

[waclawek.jan]

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

[Clara1]

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

[waclawek.jan]

Hi @Clara1 ,

Thanks for letting us know.

Jan