STM32L476 MSI + PLL

[turboscrew]

Posted on October 13, 2017 at 19:37

What is the magic that PLL doesn't want to let go of MSI?

I've been trying to switch MSI + PLL ON/OFF during STOP2 mode (to save battery), but the MSI + PLL hangs on for about 15 milliseconds. I'm first switching onto HSI16 to 'free' PLL and then turning OFF the PLL and then setting PLL clock source to NONE. I've also tried turning the SAI1 and SAI2 PLLs off before disabling the main PLL, but that didn't seem to be the problem. Also going to STOP2  with PLL left ON seems to make it hard to get the MSI + PLL started after wakeup.

The PLL comes off from HSE normally.

#stm32l476 #pll #msi

[Tesla DeLorean]

Posted on October 15, 2017 at 18:21

Not sure the value of switching to HSI, MSI should surely already be running, can't you switch to that? The PLL needs to be off to be configured, you should check it's state and review RCC register settings in the various start up conditions.

16ms to start and switch to the PLL does seem excessive based on my reading of the DS and RM

Debuggers may interfere with these processes, would recommend instrumenting via GPIO and USART to quantify modes and start times.

[turboscrew]

Posted on October 15, 2017 at 23:26

I'm switching to HSI to get system clock off the PLL. Otherwise the PLL and MSI can't be stopped. I'm trying to disable PLL and make its clock source NONE for faster setup after wakeup. If I started with MSI I couldn't put the PLL on it...

I wonder what state the clocks/PLLs would be if I didn't stop anything, but just let the stop2 to disable them...

It's hard to check the clock/PLL status bits, because the uC doesn't go to stop2 if debugger is attached. I don't have time to set up an USART either. :(

Maybe I'll try with leds.. (there are 2 leds).

16ms to start and switch to the PLL does seem excessive based on my reading of the DS and RM

And the funny thing is that with HSE+PLL there is no such problem It gets ON and OFF in less than 3 ms.

[turboscrew]

Posted on October 16, 2017 at 18:40

Any idea why this doesn't work?

  __HAL_RCC_PLLSAI1_DISABLE();

  __HAL_RCC_PLLSAI2_DISABLE();  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;  RCC_OscInitStruct.MSIState = RCC_HSI_ON;  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_NONE;  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_NONE;  HAL_RCC_OscConfig(&RCC_OscInitStruct);    HAL_RCC_ClockConfig(...)    __HAL_RCC_PLL_DISABLE()

/* let the stop2 kill the clocks and PLLs */

(go to stop2 for about 100 ms)

(wakeup)

/* just in case... */

  __HAL_RCC_PLLSAI1_DISABLE();

  __HAL_RCC_PLLSAI2_DISABLE();  __HAL_RCC_PLL_DISABLE()  __HAL_RCC_PLL_PLLSOURCE_CONFIG(RCC_PLLSOURCE_NONE)

  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_MSI;

  RCC_OscInitStruct.MSIState = RCC_MSI_ON;  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_MSI;  HAL_RCC_OscConfig(&RCC_OscInitStruct);

  HAL_RCC_ClockConfig(...)

...

[Tesla DeLorean]

Posted on October 16, 2017 at 19:13

You fill the PLL parameters some place? Enable asserts check if it throws errors or ends up in a handler or while loop.

Fully initialize structures out of wake.

[turboscrew]

Posted on October 16, 2017 at 20:13

I just didn't put everything there, and I've gone through the HAL-sources. It doesn't hang into any of the asserts. (Checked that with 'fake sleep' - a loop waiting for the wakeup interrupt to set a flag instead of going to stop2.) It looks like the chip doesn't wake up at all. (The wakeup is done by LPTIM1 on LSE.)

Maybe I should have put at least dots...

RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_MSI;

... (PLL parameters)

HAL_RCC_OscConfig(&RCC_OscInitStruct);

Oh, and the not waking up... the core current consumption stays in a couple of microamps.

And HSI16 is set as the wakeup clock.

[Tesla DeLorean]

Posted on October 17, 2017 at 00:00

Perhaps you can furnish a minimally complete demonstration.

[turboscrew]

Posted on October 17, 2017 at 19:15

It may be difficult - an at least will take some time. I had that problem at work, and can't use that code. I don't even have the code at home... I'll see if I can...

I don't have any L476-based boards myself.

[Tesla DeLorean]

Posted on October 17, 2017 at 20:34

The NUCLEO-L476RG runs about $14, target something like that, if it becomes an ST side problem you'll have something for them to shoot at. I can't spend my time speculatively building a framework to demonstrate if there is an issue or not, but I can look at something that demonstrates a problem to understand what's happening and if it an issue on the coding/library side, or if it seems more HW specific. Trying to do static analysis on heavily edited or redacted code assumes the code you are showing actually causes the issue, which frequently isn't the case.

If it is a work issue, they would need them to fund your effort to create a minimally complete example that doesn't expose any business related secrets. Work with your local FAE

[turboscrew]

Posted on October 18, 2017 at 19:28

I'm painfully aware of the difficulty, and thanks for your effort. I managed to get things working - I still don't quite know how.

I try to gradually put some demonstration together, but don't hold your breath - it may take quite a while especially now when I've been quite busy. I don't think the company wants to put a dime in figuring out what happened now that it's working, so I need to do it all on my own...