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.

[waclawek.jan]

Can you connect with debugger? If yes, read out and check/post content of GPIOA_MODER/GPIOA_AFR and RCC_BDCR.

JW

[Tesla DeLorean]

Does your design pull BOOT0 low?​

[na]

Sorry, but no. We can't connect a debugger. It's protected, so if we connect a debugger it will erase everything. We have our own debug-output on this UART....

[na]

Boot0 is pulled low (by a 10k resistor).

[waclawek.jan]

Do you have a battery connected on VBAT? Do you have a 32.768kHz crystal connected and used as LSE?

Do you use Cube/HAL to initialize LSE and/or RTC? If yes, do you correctly set/clear *all* fields of the init struct before initializing LSE/RTC?

JW

[na]

I'm using a PSU (tried with several different ones). The unit can be out of power for a long time, and when it starts up it starts to generate this wave again.

I'm not sure how this initilize is done (it's not me who have made it), but we suspect that it's not a SW thing. We have produced several 1000 of this PCB and we only see this on very few units. Units where the power have been cycled on/off for many times (mainly in our test system).

And yes, we have a 32,768kHz on the OSC32-pins. That was my first thought that it was that clock being routed to this pin, (for some strange reason), but it's not the same frequency. I can run a test-command and put out our 32,678 clock on another pin, so I measured both at the same time with the oscilloscope, and they differed.

[waclawek.jan]

> we suspect that it's not a SW thing

Show code which performs the LSE/RTC initialization.

> I can run a test-command and put out our 32,678 clock on another pin,

Using those test commands, can you read out RCC_BDCR somehow?

Or output LSI?

JW

[S.Ma]

Does your application meet all the stm32 electrical requirements respective to power up and sown supplies, slope, droops? What happen if you add say a 1 sec sw delay when the mcu is leaving low power mode? Is the pin configuration atomic in case or RTOS or gpio configured within interrupt/callback? Does the pin has MCO alternate on LSI ?

[na]

Since we found out that, according to STM32 Application Note, LSCO can be output on PA2, it's safe to assume this is what we see. Question is, how can RCC_BDCR:LSCOEN suddenly be enabled? I don't think we ever touch this register except for setting RTCSEL and RTCEN, which we do via HAL/LL.