Dead LSE and PLL

[Peaga]

Hello!

It's been a while since my project is working fine with STM32H750, using HSI (+PLL) as SYSCLK and RTCC by LSE (crystal and capacitors selected by ST notes). But (maybe) after an abrupt reset by the power suplly, two of my custom boards starts to act weird. GPIO toggle became very slow and RTCC stop working at all.

Putting the board on debug, I found that both HAL_RCC_OscConfig() and HAL_RCC_ClockConfig() are returning error: the first one, a HAL_TIMEOUT on "LSE Configuration" and the second, HAL_ERROR on "PLL is selected as System Clock Source".

After replacing ST from one of the boards, everything starts to working fine. So I'm really confused. Is it really dead? But how??

Thanks in advanced

[Tesla DeLorean]

I don't recall seeing any. I have flagged this for review.

[waclawek.jan]

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

[Amel NASRI]

Hi @Community member​,

Checking STM32H750 and STM32H743 errata sheets, there are mainly 2 LSE related limitations:

• LSE oscillator driving capability selection bits are swapped
• LSE CSS parasitic detection even when disabled

Please make sure that you are applying required workarounds for these limitations.

-Amel

[AScha.3]

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..)

[Amel NASRI]

Hi @AScha.3​ ,

Based on this table from the errata sheet, LSEDRV should be set to "10" to be in the low drive as effective mode.

-Amel

[ADunc.1]

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?

[GLASS]

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...​

[Amel NASRI]

Hi @Community member​ ,

However, the errata document makes no mention of variant and suggests this issue applies to all revisions???

Limitation applies to rev Y only:

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

No software workaround suggested for the limitation "LSE CSS parasitic detection even when disabled". This is what we suggest:

This applies to all product revisions.

-Amel

[ADunc.1]

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.

[ADunc.1]

Thanks @GLASS​ . I was under the impression that if LSE was already on, then there was no significant time lost waiting for LSERDY to be set. The CubeMX code just sets bits the LSE register as needed (which will be exactly the same as the previous startup), so LSE functionality should not be changed during a restart. and as the LSE is already running, LSERDY should already be set so no time lost waiting for it to be set. But, I have not done any software debugging to check this is actually the case in practice, but I did watch the oscillator on the scope during a reboot and it is not stopped/restarted so LSERDY should be set all the time.