Sporadic issue with the LSCOEN bit being set in the RCC->BDCR register

[S.Ryeskov]

We are working with an STM32L476JGY6TR with a project generated through cube, and we have sometimes seen a sporadic issue with the LSCOEN bit being set in the RCC->BDCR register. This causes the LSE clock to be output on PA2 where we are using the UART.

We have mitigated the problem by explicitly setting the BDCR register to all zero before calling SystemClock_Config() and disabling access to the backup domain. However, we do not know exactly why this happened and whether it may happen during runtime. So far we've seen the problem at boot-up (reports from different developers are not clear on if it is only at boot-up or if it also occurred runtime).

We never set the LSCOEN bit on purpose at any point in our program. We want to be sure that it doesn't happen again during runtime.

Any help and/or tips is greatly appreciated.

[waclawek.jan]

How is VBAT connected?

Couldn't this be consequence of backup-domain brownout?

JW

[S.Ryeskov]

VBAT, VDD, VDDIO2, VDDUSB and VDDA are all connected to the same 3.3V., each with a 100 nF cap.

VRef+ is connected to a sperate voltage.

I read the article in the link, and I guess we cannot rule out that it is a brownout.

[FBL]

Hello @Søren Olander Ryeskov​ 

The access to RTC and Backup registers are protected against parasitic write access through DBP. You can check when the backup domain is accessed. Also, you can make sure when LSCOSEL is set to be sure LSCO is generating LSE.

Could you check if LSE drive is being programmed before enabling the LSE?

[S.Ryeskov · Accepted solution]

Hello @F.Belaid​ 

I have talked to technical support about this and the recommended solution is in line with the artivle @Community member​ linked to. The specific solution is to manually reset the backup domain and ensure that the LSCOEN bit is cleared.