STM32L4 LSI and power-down sequance

[shachar y]

Posted on January 14, 2018 at 09:25

Hello,

In our Evaluation board of the STM32L486QG we encounter in strange behavior of the MCU.When the power supply turned off and on quickly we saw that sometimes the MCU start to getting in to loops of IWDG.We are using the LSI as the IWDG source and we saw that when it happens the frequency of the LSI is ~ 48KHz and not as it should be ~ 32KHz.We are not sure that this simptom is the problem, and we will apprciate your help.Another thing that we noticed is that if the MCU voltage supply did not discharge to 0V but to around 0.7V the registers in the backup domain does not clearing.We saw that for example LSERDY bit does not clear.Is there any power-down and power-up sequance that we need to follow?

Thanks in advanced,

Shachar#stm32l4

[StéphaneM]

Posted on June 08, 2018 at 16:11

Hello Sachar,

we are currently investigating a similar issue and would like to know more about your setup.

What is the LSI clock used for in your setup (other than clocking the IWDG) ?

For instance, is the LSI clock used as an input clock for the RTC ?

Best regards,

Stéphane

[shachar y]

Posted on June 13, 2018 at 10:34

Hello 

Stéphane,

The LSI is used only for the IWDG.

For the RTC we are using the LSE clock.

Plese let me know if you found anything that couuld help with my case.

Thank you,

Shachar

[StéphaneM]

Posted on June 19, 2018 at 16:33

Hello Sachar,

yes, we are observing something similar but in different conditions.

Could you tell :

1/ Whether you are using the LSE Clock Security System (setting the LSECSSON bit) ? 

2/ Whether you observe the issue while in low power mode (Stop1, Stop2, Standby or Shutdown mode) ?

3/ Whether you have an independent supply on Vbat while the power drop occurs on VDD ?

Best regards,

Stéphane

[shachar y]

Posted on June 20, 2018 at 08:23

Hello Stéphane,

1. We are using the clock security system on the LSE clock.

2. We are switching from run mode to stop2 mode, It was hard to determine if the issue occurred only when we are in stop2 or in run.3. In our system the Vbat is tied to VDD so they droped together.

Best regards,

Shachar

[StéphaneM · Accepted solution]

Posted on June 22, 2018 at 15:03

Hello Sachar,

the fact that you are using the Low Speed External Clock Security System (LSECSSON bit set) confirms our hypothesis.

Here is the failure mechanism that you observe :

- in your application, you are enabling the LSI clock in order to use the LSE CSS- the LSI clock is requested from the backup domain (where the LSE CSS sits)- a short glitch on VDD resets the Vcore domain (thanks to the BOR mechanism) while the backup domain is not reset (dependent only on the POR mechanism)- upon BOR reset release, the LSI is still running as it is requested by the backup domain- the option bytes loading is launched while the LSI is already running (which is forbidden by spec)- a wrong value is used a trimming value for the LSI which corrupts its duty cycle and frequency

As your VBAT is connected to VDD, there is a simple workaround.

You have to reset the backup domain (procedure available in RM0351 chapter 6.1.3 Backup domain reset) after each VDD power up (by checking the BORRSTF flag).

Later in your code, re-enable the LSI and it will oscillate correctly.

Best regards,

Stéphane

[waclawek.jan]

Posted on June 22, 2018 at 15:30

Stéphane,

so, this problem (incorrect LSI trim) is inevitable if battery is connected to VBAT and LSE CSS is on, right?

Thanks,

JW

[StéphaneM]

Posted on June 25, 2018 at 10:37

Hello Jan,

You are correct. You may also face this issue if VBAT is supplied by an independent power supply and if LSE CSS is used.

Best regards,

Stéphane