Question
STM32H563 LSE does not always start
I am using an stm32h563 nucleo 144 board, and I am frequently running into the issue that after a power cycle the LSE does not start.
This is the relevant part of my SystemClock_Config:
LL_PWR_EnableBkUpAccess();
while (LL_PWR_IsEnabledBkUpAccess () == 0U)
{
}
LL_RCC_LSE_SetDriveCapability(LL_RCC_LSEDRIVE_LOW);
LL_RCC_LSE_Enable();
/* Wait till LSE is ready */
while (LL_RCC_LSE_IsReady() != 1)
{
}
and LL_RCC_LSE_IsReady() never returns 1 in that case, no matter how long I wait.
Also, I can reflash a debug firmware via SWD, attach the debugger, and still end up in the same loop.
I need to power cycle the board again, to resolve this issue.
However, I will need a software workaround, which does not require a power cycle, because I fear that we will get the same issue in the field, with our final product (which will be based on the STM32H563, and will be using an LSE in the same configuration as the nucleo board)
This is what I came up with as a workaround:
LL_RCC_LSE_SetDriveCapability(LL_RCC_LSEDRIVE_LOW);
LL_RCC_LSE_Enable();
/* Wait till LSE is ready */
int count = 0;
while (LL_RCC_LSE_IsReady() != 1 && count < 10000000)
{
count++;
}
if (count >= 10000000)
{
/*
* NOTE: the timing of this is quite critical.
* If we do not wait for LSE_IsReady long enough, the backupdomain reset does not fix the issue.
* So even though after a few attempts we can already conclude the LSE is not going to start,
* we still wait for 10000000 attempts, because we should not reset too early.
*/
LL_RCC_ForceBackupDomainReset();
LL_RCC_ReleaseBackupDomainReset();
__NVIC_SystemReset();
}
But, I found that the timing is quite critical. When I use 1000000 loops instead of 10000000, the workaround still works with a debug build (-O0), but not with a release build (-Os).
Also, when the LSE starts normally, LL_RCC_LSE_IsReady() returns 1 right away, without even a single loop. So even after a few cycles we could already conclude the LSE does not start. But somehow we need to wait for quite some time (almost 3 seconds) before the backup domain reset causes the situation to be recovered.
My questions:
Do you have an explanation for this issue?
Do you perhaps have a better way to work around it (or even avoid it)?
