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.

[ABeus.1]

10 test systems here with STM32L451RCT6 and identical HW/SW.

One of the 10 produces the problem quite often. Not observed on the 9 others.

Once it appears, it reappears at every following startup.

I noticed that after power down there is a residual VDD voltage of about 0.5 VDC.

The problem goes away if I short circuit VDD to GND and release the short afterwards.

It is completely reproducible, bringing VDD to 0 V clears the fault.

The error can reappear after a further power off. BOR ist set to level 1.

[waclawek.jan]

Everything wrote above applies. Check with debugger - or by instrumenting the code in any available way - the backup domain register settings, especially after the problem occurs.

JW

[ABeus.1]

How can the variation between chips be explained, HW/SW being identical?

[waclawek.jan]

That's not "between chips", it's "between boards"; and there is nothing like "identical". There's an infinite number of small variations, e.g. leakages between pins, exact timing of power up ramp on individual power pins depending on minor variations in capacitors capacitance and a myriad of other things on the board, different exact thresholds of a couple of million transistors on the chip, and its consequence, which may be quite likely the case here, the inherent tendency of a SRAM cell to power up in a given state. I am no clairvoyant.

Try to find the mechanism how this happens, that may lead you to the explanation of the variation. Start with reading out the backup domain registers and compare for "good" and "bad" state.

JW

[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