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.

[PHolt.1]

OK will do. I didn't do it because posts with no or few replies tend to get no response :)

[bns23]

It looks like we have the same issue here with an STM32F412CG.

Both VDD and VBAT are powered together by a switching regulator that will retain the power supply through some GoldCaps when the input voltage to the device is powered off. But after the switching regulator turns off because the GoldCaps are empty, it will still provide some hundred mV to VDD and VBAT.

We observe, on 2 of 20 devices that are tested, that registers contain strange values. The LSEON (external low frequency oscillator enable) bit in RCC_CSR was sometimes set, causing the peripheral clock initialization to fail and our device to "freeze" because init waits until the LSE is stable, but this does not happen because we do not have an external low frequency oscillator equipped.

After I removed the peripheral clock initialization, we also observed that PC13 pin lost its function as an input sometimes. I assume here the pin has been configured for some RTC related special function like mentioned in the reference manual.

I now added a routine to reset the backup domain directly after SystemClock_Config() - can someone please tell me if this is correct?

void ResetBackupDomain()
{
    /* on displayUnitA, we observed issues with randomly set bits in backup domain registers.
     * See http://www.efton.sk/STM32/gotcha/g133.html for a description
     */

    uint32_t tmpreg;

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

    /* read back for a delay - see errata, "possible delay in backup domain protection" */
    tmpreg = PWR->CR;

    __HAL_RCC_BACKUPRESET_FORCE();
    __HAL_RCC_BACKUPRESET_RELEASE();

    tmpreg &= ~PWR_CR_DBP;
    PWR->CR = tmpreg;
}

This issue isn't mentioned in the errata sheet, but only in errata for STM32G071x8/xB (section 2.2.11 of https://www.st.com/resource/en/errata_sheet/es0418-stm32g071x8xb-device-errata-stmicroelectronics.pdf)
I think ST should add it to the errata of the affected devices.

best regards,

Frank

[waclawek.jan]

It looks OK, provided that PWR's clock in RCC has been set previously (and doing that while observing the needed delay between enabling clock and accessing peripheral... :) )

JW