LSE fault recovery

[Clonimus74]

Hi all,

Using STM32L476.

I had some issues with LSE (ready flag is never set), and so I experimented with different capacitors.

During our experimentation I tried to intentionally cause the LSE to fail (never mind why) by touching its capacitors with my finger. Once the LSE failed it never recovers, even if I reset the system the LSE will keeps failing, until I remove the battery/power supply completely.

That means that if there's a fault with the LSE, for any reason, the system cannot recover by turning the LSE drive off and on, not even system reset. Is that normal? Is there a solution?

Removing the battery is not an option, the battery is not removable, and power off doesn't cut the power just puts the system in standby.

EDIT:

forgot to add my code, adding just the relevant parts -

initialization:

  LL_RCC_LSE_Enable();
 
  timeout = 0;
  while ((LL_RCC_LSE_IsReady() != 1) && (++timeout < eMCU_DELAY_2_5SEC));
  if (timeout >= eMCU_DELAY_2_5SEC)
  {
    system_health_flags |= e_LSE_FAILED;
 
    LL_RCC_SetLPTIMClockSource(LL_RCC_LPTIM1_CLKSOURCE_LSI);
    LL_RCC_SetRTCClockSource(LL_RCC_RTC_CLKSOURCE_LSI);
    LL_RCC_LSE_Disable();
  }
  else
  {
    LL_RCC_SetLPTIMClockSource(LL_RCC_LPTIM1_CLKSOURCE_LSE);
    LL_RCC_SetRTCClockSource(LL_RCC_RTC_CLKSOURCE_LSE);
  }
 
  LL_RCC_EnableRTC();
 
  HAL_RCCEx_EnableLSECSS_IT();

LSECSS interupt:

/**
* @brief This function handles RTC tamper and time stamp, CSS on LSE interrupts through EXTI line 19.
*/
void TAMP_STAMP_IRQHandler(void)
{
  if (__HAL_RCC_GET_IT(RCC_IT_LSECSS))
  {
    HAL_RCCEx_LSECSS_IRQHandler();
  }
}

LSECSS callback:

/**
  * @brief  RCCEx LSE Clock Security System interrupt callback.
  * @retval none
  */
void HAL_RCCEx_LSECSS_Callback(void)
{
  if (__HAL_RCC_LSECSS_EXTI_GET_FLAG() || __HAL_RCC_GET_FLAG(RCC_FLAG_LSECSSD))
  {
    system_health_flags |= e_LSE_FAILED;
    HAL_PWR_EnableBkUpAccess();
    HAL_RCCEx_DisableLSECSS();
    __HAL_RCC_LSECSS_EXTI_DISABLE_IT();
    LL_RCC_LSE_Disable();
 
    if (__HAL_RCC_GET_RTC_SOURCE() == RCC_RTCCLKSOURCE_LSE)
    {
      __HAL_RCC_RTC_DISABLE();
      __HAL_RCC_BACKUPRESET_FORCE();
      __HAL_RCC_BACKUPRESET_RELEASE();
      LL_RCC_SetRTCClockSource(LL_RCC_RTC_CLKSOURCE_LSI);
      LL_RCC_EnableRTC();
      MX_RTC_Init(&flags);
    }
    __HAL_RCC_LSECSS_EXTI_CLEAR_FLAG();
  }
}

[After Forever]

Are you enabling the LSE Clock Security System in your code?

[Clonimus74]

Yes CSS is enabled, also tried when it is disabled. Once LSE failed, after reset it will always fail in the initialization stage (enters line #7)

[Danish1]

I didn't spot which stm32 micro you are using.

I note that in the stm32f101xC/D/E stm32f103xC/D/E errata dated April 2014 they mention putting a large resistor (16 MOhm to 22 MOhm) in parallel with the crystal to improve startup in harsh environments. (I haven't used stm32f103 since then so I haven't bothered to download a more-recent errata sheet).

One thing you might try, once you have determined that LSE has failed, is to discharge the pins before trying to restart LSE. This would be by temporarily reprogramming the LSE pins to be general-purpose digital outputs, level 0. This might remove any stray charge that had been left by your finger.

This might be fine for development / debugging purposes. What you do for production is a different matter, because (I assume) fingers can't normally get to the tracks. If you get an LSE failure, it is a sign of a fault on the board - so for safety-critical components it should signal that it needs servicing? Should it enter a "fail-safe" mode, where it carries on operating but at reduced performance (e.g. burning extra power to keep another oscillator going)?

If I see this during production-test, I would reject the board, returning it for rework.

Hope this helps,

Danish

[Clonimus74]

Sorry. I use STM32L476.

They specifically say no to put resistor there =)

I don't know what can cause an LSE to fail. When it does I transition to LSI, I would like it if the LSE is OK that after reset the system will use it again.

In my experiments the LSE itself is OK I just forced it to fail, and after multiple resets it kept failing, after power cycle it recovered.

[Danish1]

I'm not sure if you read the whole of my reply ("Show More").

If not, please try my suggestion. Either at reset or if you detect LSE-failure, to program both LSE pins (PC14 and PC15 perhaps) to be GPIO output LOW.

Hold that for a few milliseconds before initialising / enabling the LSE. This might be sufficient to discharge whatever was injected by your finger, allowing the LSE to (re)start.

Regards, Danish

[Clonimus74]

I tried it, didn't help :pensive_face:

[Clonimus74 · Accepted solution]

I found the problems.

1. I initialize the LSE in the bootloader and application and so it can happen that I increase the drive while LSE is enabled and ready.
2. In case of CSS fault, disabling the CSS doesn't clear the error flag (RCC_FLAG_LSECSSD) and so the LSE cannot be re-enabled. Backup domain reset must happen in order to reset the fault and re-enable the LSE

[waclawek.jan]

Thanks for coming back with the solution

> I case of CSS fault, disabling the CSS doesn't clear the error flag (RCC_FLAG_LSECSSD) and so the LSE

> cannot be re-enabled. Backup domain reset must happen in order to reset the fault and re-enable the LSE

This appears to be a key information missing from the RM.

JW

[Amel NASRI]

Hi Jan,

LSECSSD is a bit in Backup domain control register (RCC_BDCR).

When describing this register in the reference manual, there is the following note:

"These bits (except LSCOSEL, LSCOEN and BDRST) are only reset after a

Backup domain Reset (see Section 6.1.3: Backup domain reset). Any internal or external

Reset will not have any effect on these bits."

So the information is there, in the reference manual.

-Amel