constant square wave on USART2_TX (PA2) after a power cycle (brown-out)

[na]

We get a constant square wave on USART2_TX (PA2) on some of our STM32L451CEU6TR products. This seems to happen sometimes after a power cycle (brown-out). The square wave is a around 32kHz.

As mentioned, this only happens on a few of our units, and after it has happened it doesn't seem to go away. It comes back after a power cycle event or a reset. One of the first thing we do, is to write on the UART, but we never see this, the oscillations starts before that (and the UART data will not come through after that). But the USART2_RX (PA3) still works. We can still send data to the MCU. The 32kHz isn't the same as the 32,768kHz. It's a little bit lower (like 31,9...). This was one of our thoughts that there had happened some HW changes inside the MCU so the RTC-clock was ported out here. But this doesn't seem to be the case.

[jtim.1]

We met this problem in our product too. Not only RCC_BDCR:LSCOEN, but also RCC_BDCR:LSCOSEL, RTC_WUTR and RTC_ALRMBR is not the reset value, which we never touch .How did you solved this problem finally?

[jtim.1]

Did you use mcuboot as bootloader?

[waclawek.jan]

We've mentioned the uninitialized structs, because it overwrites fields which you thought you've explicitly set, and that's a surprise. And also it is a quite common theme here (or at least used to be).

What is mc​uboot?

JW​

[Eis]

If I remember, we just added an LL_RCC_LSCO_Disable() with an angry comment in the RTC initialization code to reset the critical bits. Not the most satisfying solution, but we haven't seen the problem since :)

[waclawek.jan]

@Eis​ , @André Beusch​ , @jtim.1​ ,

Read ES0418 - Rev 4, "Corrupted content of the RTC domain due to a missed power-on reset after this domain supply voltage drop"

I know it's for 'G0, but this sort of errata pertains to the whole range of mcus built with the same technology, and ST is not famous for promptly propagating errata across families.

JW

[PHolt.1]

This is quite an amazing topic. I reckon not many find the problem because not many use the RTC.

I implemented Vbat measurement (using the ADC1 ch 18 method - 32F417/437) as detailed here

https://www.eevblog.com/forum/microcontrollers/will-stm32f4-start-if-vbat-is-lo-or-floating-due-to-dischargedunfitted-cell/

However I still think one needs to write to some RTC / low power domain registers at every power-up, obviously done so as to not corrupt the RTC. I think the ST code (the ex MX stuff) does that but it is so convoluted, with typedefs of typedefs of structs, that I can't decipher it.

[waclawek.jan]

> However I still think one needs to write to some RTC / low power domain registers at every power-up

If VBAT was within spec all the time, no.

JW

[PHolt.1]

Hmmm, that seems self evident even to me : - )

It probably means that people who use a battery, or don't turn off the power, won't see this problem, and won't see it until some years down the road, and even then they probably will not report it.

It is most likely to affect supercap users because a 0.22F supercap powers the 32F417 RTC for about 3-5 days. But even then only if there is power cycling going on, with an OFF interval of some days.

BTW has this forum software been changed so as to eliminate the "click here for more posts" suicide-inducing feature?

[PHolt.1]

I have spent a lot of time doing the backup domain reset at power-up.

Some context is here
https://www.eevblog.com/forum/microcontrollers/will-stm32f4-start-if-vbat-is-lo-or-floating-due-to-dischargedunfitted-cell/

It turns out that the ultra convoluted ST code does a reset, in HAL_RCCEx_PeriphCLKConfig() but it does it only when certain bits in BDCR are unchanged. Does anyone know why?

	/*---------------------------- RTC configuration ---------------------------*/
	if(((PeriphClkInit->PeriphClockSelection) & RCC_PERIPHCLK_RTC) == (RCC_PERIPHCLK_RTC))
	{
		/* Check for RTC Parameters used to output RTCCLK */
		assert_param(IS_RCC_RTCCLKSOURCE(PeriphClkInit->RTCClockSelection));

		/* Enable Power Clock*/
		__HAL_RCC_PWR_CLK_ENABLE();

		/* Enable write access to Backup domain */
		PWR->CR |= PWR_CR_DBP;

		/* Get tick */
		tickstart = HAL_GetTick();

		while((PWR->CR & PWR_CR_DBP) == RESET)
		{
			if((HAL_GetTick() - tickstart ) > RCC_DBP_TIMEOUT_VALUE)
			{
				return HAL_TIMEOUT;
			}
		}
		/* Reset the Backup domain only if the RTC Clock source selection is modified from reset value */
		tmpreg1 = (RCC->BDCR & RCC_BDCR_RTCSEL);
		if((tmpreg1 != 0x00000000U) && ((tmpreg1) != (PeriphClkInit->RTCClockSelection & RCC_BDCR_RTCSEL)))
		{
			/* Store the content of BDCR register before the reset of Backup Domain */
			tmpreg1 = (RCC->BDCR & ~(RCC_BDCR_RTCSEL));
			/* RTC Clock selection can be changed only if the Backup Domain is reset */
			__HAL_RCC_BACKUPRESET_FORCE();
			__HAL_RCC_BACKUPRESET_RELEASE();
			/* Restore the Content of BDCR register */
			RCC->BDCR = tmpreg1;

			/* Wait for LSE reactivation if LSE was enable prior to Backup Domain reset */
			if(HAL_IS_BIT_SET(RCC->BDCR, RCC_BDCR_LSEON))
			{
				/* Get tick */
				tickstart = HAL_GetTick();

				/* Wait till LSE is ready */
				while(__HAL_RCC_GET_FLAG(RCC_FLAG_LSERDY) == RESET)
				{
					if((HAL_GetTick() - tickstart ) > RCC_LSE_TIMEOUT_VALUE)
					{
						return HAL_TIMEOUT;
					}
				}
			}
		}
		__HAL_RCC_RTC_CONFIG(PeriphClkInit->RTCClockSelection);
	}

[waclawek.jan]

The comment says it: it resets the backup domain only if it is not in reset state and you want to change the RTC clock source. The reason has nothing to do with the VBAT-domain brownout-induced corruption/erratum, it's relatively new after all ; Cube/HAL does it because of:

To discuss your particular setup further please start a new thread, perhaps linking to this one (and the eevblog one) as appropriate.

JW