Dead LSE and PLL

Hi! I confirm this problem.

We have three identical boards. Boards core - STM32H743VIT6 rev. Y.

During debugging, LSE stops working on one board.

Trying to change the quartz driving level :

{ 

LL_PWR_EnableBkUpAccess();

 LL_RCC_ForceBackupDomainReset();

 LL_RCC_LSE_SetDriveCapability(LL_RCC_LSEDRIVE_HIGH);

}

RCC->BDCR->LSEDRV does not change (RCC->BDCR->LSEDRV = 0 ). On other boards and on this one after replacement MCPU, the code works (RCC->BDCR->LSEDRV = 3 ) , LSE works.

This is a big problem. In a real project, the failure of this module and, as a result, the failure of the RTС.

Refusing STM32H7? What says support?

Hello, I confirm the issue. Im working on a custom board with stm32h743vi.

May be a fail in some MCUs, I allready have 100 boards running, 3 of them has the RTC issue after a power down.

LL_RCC_LSE_SetDriveCapability(LL_RCC_LSEDRIVE_HIGH); doens´t take any effect.

any solution?

I found a solution.

You must disable LSE before change drive capability

 LL_PWR_EnableBkUpAccess();

 LL_RCC_LSE_Disable();// add this line

 // LL_RCC_ForceBackupDomainReset(); // comment this line

 // LL_RCC_ReleaseBackupDomainReset(); // comment this line

 LL_RCC_LSE_SetDriveCapability(LL_RCC_LSEDRIVE_HIGH);

 LL_RCC_LSE_Enable();

  /* Wait till LSE is ready */

 while(LL_RCC_LSE_IsReady() != 1)

 {

 }

I'm going to test this in several boards...

best regars

Diego

Thanks!

I also have this same problem. Three products have been returned from the field where they will not startup due to LSE not starting. When the battery is removed and power is cycled, the LSE starts working again and remains working through power cycles.

This is without altering the drive level.

Did anybody find anything further about this issue?

Read out and check/compare-to-working/post content of the relevant RCC register(s) (I don't use 'H7, in many STM32 it's RCC_BDCR).

JW

just my 2 cts : we had also problems with start of H7xx , when drive level of LSE is low (default);

so we set drive level high (or medium high) , then all running as they should . (about 500 boards now..)

Thanks everybody for your answers.

I did check errata and saw the issue about LSE driving bits swapped. I also noted in the STM32H7 cube library that the macro to set oscillator driving capability checks device revision and the swapped bits only apply to revision Y, I am using revision V. However, the errata document makes no mention of variant and suggests this issue applies to all revisions???

#if defined(RCC_VER_X)
#define __HAL_RCC_LSEDRIVE_CONFIG(__LSEDRIVE__) \
 do{ \
 if((HAL_GetREVID() <= REV_ID_Y) && (((__LSEDRIVE__) == RCC_LSEDRIVE_MEDIUMLOW) || ((__LSEDRIVE__) == RCC_LSEDRIVE_MEDIUMHIGH))) \
 { \
 MODIFY_REG(RCC->BDCR, RCC_BDCR_LSEDRV, (~(uint32_t)(__LSEDRIVE__)) & RCC_BDCR_LSEDRV_Msk); \
 } \
 else \
 { \
 MODIFY_REG(RCC->BDCR, RCC_BDCR_LSEDRV, (uint32_t)(__LSEDRIVE__)); \
 } \
 } while(0)
#else
#define __HAL_RCC_LSEDRIVE_CONFIG(__LSEDRIVE__) \
 MODIFY_REG(RCC->BDCR, RCC_BDCR_LSEDRV, (uint32_t)(__LSEDRIVE__));
#endif /*RCC_VER_X*/

I am currently using low drive capability. From calculations for our crystal, this gives a gain margin of three. This is a bit lower than the minimum of five recommended. Going up to the second drive power level would bring this to almost exactly five. I need to wait for access to an appropriate low capacitance scope probe so I can do some measurements. I do not want to over drive the crystal. There are too many units out in the field to change without full verification.

We have powered up these boards literally more than 20000 times and only ever had three known cases of the oscillator not starting. In all cases the product passed internal testing and failed to start after installation in the field (while running in battery backup). The first two of these boards "fixed themselves", most likely due to the techs removing the backup battery. The third board is on my desk to be diagnosed.

Some how I missed the note in errata about "LSE CSS parasitic detection even when disabled". Not sure how I missed that, I searched for "LSE"!!!

While the board was in a state where LSE would not start, I connected the debugger and had a look at the RCC->BDCR register bits. I did notice that the LSECSSD bit was set, but because LSECSSON was clear I did not think it was relevant. So, it seems possible that these boards are experiencing the issue described in the errata. Possibly experiencing ESD during installation.

Unfortunately I removed and re-fitted the battery from my test board and it has been perfect ever since. The oscillator starts in 800ms, I tested in a thermal chamber over -10 to +40 and it starts every time. So, unlikely I will be able to reproduce the issue again. I will try the ESD gun though!

From the errata "The LSECSSD flag in RCC_BDCR register can be spuriously set in case of ESD stress when the device is in VBAT mode, even if the CSS on LSE is disabled. The LSE clock is no longer propagated to the RTC and the system, even if the LSE oscillates, as long as the LSECSSD flag is set. LSECSSD can be cleared only by a Backup domain reset."

So, what is the software workaround for this? Software reset of the battery backup domain? Wont this mean the RTC time is also lost?

The errata suggests the LSE will still operate even if LSECSSD is set. The problem I see in practice is that LSERDY never becomes set during clock configuration (standard STM32CubeMX generated clock init code). SystemClock_Config times out waiting for LSE start. So if LSECSSD is set, will LSERDY be able to be set or not?

If you use cube mx generated code, be sure that you don't restart LSE and don't init RTC for each Hot start.

Because those init MUST be done only when backup domain lost or the very first startup.

Doing so you have benefits :

1)No more inaccuracy (LSE startup time and the big one : don't lost between 0 to 1 second for each boot...)​

2) LSE startup are not frequent so dimuning possibilty of not starting.

​

To do that you need at each boot to detect if LSE is already running to avoid unnecessary restart...

​

It was experimented in the past with F4 and F7...not yet using H7 here...​

​

​

Thanks for your feedback @Amel NASRI​ . Unfortunately a hardware workaround will not stop our products that are already in the field from having this issue. A lot of these products were shipped before the errata was even updated with mention of this issue.

There must be some sort of workaround that can be managed in software. Such as if the LSE wont start, do a software reset of the backup domain. The reference manual is very vague on the CSS function so it is not completely clear to me why a CSS detection would cause the LSERDY bit to not be set? If I could better understand the function and relationship of these bits then a workaround may be possible.