Enabling over-drive on F7

[Matthew Lai]

Posted on April 18, 2017 at 01:00

Hello!

I am having trouble enabling regulator over-drive on a Nucleo-F767ZI.

I have now simplified my code down to just trying to enable OD right away after power up, which should be possible since system clock source is HSI by default, and no peripheral clocks are enabled?

After setting the ODEN bit in PWR_CR1 to 1, I still read back zero. Also, the ODRDY bit in PWR_CSR1 never gets set.

Am I missing something?

Thanks!

Matthew

[waclawek.jan · Accepted solution]

Posted on April 18, 2017 at 01:26

Am I missing something?

RCC_APB1ENR.PWREN?

JW

[Tesla DeLorean]

Posted on April 18, 2017 at 01:27

Manual says to configure and turn PLL on immediately *prior* to enabling the overdrive bit.

'Configure RCC_PLLCFGR register and set PLLON bit of RCC_CR register'

[Tesla DeLorean]

Posted on April 18, 2017 at 01:29

I could see that as being helpful...

One should review the startup code examples for HAL and Cube, the older stuff for F4 parts might also provide context/insight

[Matthew Lai]

Posted on April 18, 2017 at 01:31

*facepalm* Thanks!

I guess when they say no peripheral clocks should be enabled, that doesn't include PWR!

[Matthew Lai]

Posted on April 18, 2017 at 01:32

It was the peripheral clock not being enabled.

The manual does say to set up PLL before enabling overdrive, but it also says that's done to save startup time.

[waclawek.jan]

Posted on April 18, 2017 at 02:06

I guess when they say no peripheral clocks should be enabled,

... they should also say, why.

My guess is that the real reason is in

 the system clock will be stalled during the internal voltage set up

and ST wants to avoid confusion from users seing the consequence of this in timers and communication peripherals (seen as corrupted data in UART, potential timeout in I2C/SMB peripherals, glitch in output of I2S-driven codecs, or lock loss in more complex interfaces as USB and ETH).

JW