Switch to Lower Clock Speed - How To Do This?

[Rogers.Gary]

Posted on May 08, 2015 at 07:07

Hi,

The STM32F4 on my application uses an 8MHz crystal, and synthesized to run at a bus speed of 168MHz.

I'm doing some signal processing that really only requires a speed of 168MHz after a signal is detected. The detection of the signal could be accomplished with a clock speed as low as the crystal itself (8MHz)

Can someone please advise me on the steps on how to do this dynamically - if for example it's running at 168MHz, what should be done with peripherals, etc, to safely set the operation to a lower frequency, and upon a certain event, reset the clock speed higher.

Appreciate any links, suggestions or steps (checked through this site but found nothing)

Thanks!

#stm32f4 #clock-speed

[Danish1]

Posted on May 08, 2015 at 10:40

At 168 MHz you're running off the PLL.

To switch to a lower speed, you will need to first switch from the PLL to another oscillator i.e. HSI or HSE. If that's your target oscillator, you then just need to update the Flash latency and bus dividers as appropriate.

Most likely though you want to run the PLL at a different frequency so you need to:

Then turn off the PLL.

Then change the PLL dividers and multipliers.

Then turn the PLL back on.

While waiting for lock you can update the bus dividers for your new frequency, as well as e.g. UART baud-rate dividers.

The switch to PLL.

Caveats:

Anything asynchronous (e.g. RS232) cannot maintain baud rate over the switchover - it's bound to glitch. I'm fortunate in having RTS/CTS handshaking so I can stop a remote device from sending me stuff.

I think there might also be issues with DMA when some bus-division-ratios change (see errata) so I like to suspend e.g. SDIO transfers as well.

While you're on HSI/HSE you can't service e.g. USB.

Hope this helps,

Danish

[Tesla DeLorean]

Posted on May 08, 2015 at 19:28

it's bound to glitch.

Indeed, it's very hard to switch things. It's not sufficiently atomic, and stuff will glitch.

Changing baud rates you want to confirm TC is done otherwise stuff changes mid byte.

If it's a power play, consider if you can run at high speeds and have the idle loop WFI, reduce the period of ticker interrupts, etc.

[Rogers.Gary]

Posted on May 08, 2015 at 20:58

clive1,

It is indeed a power consumption issue. On battery equipment, the STM32F4 doing DSP ops is pretty ravenous for current. The nice thing is, I can use standard methods at slower rates to detect, which would be the only operation at that point.

If I can get away with it cleanly...it is worth trying.

[Rogers.Gary]

Posted on May 08, 2015 at 21:05

DA,

Your suggestions are appreciated and give me enough information to investigate the manual and try tackling it. The nice thing is, I have really one operation to suspend  - the Timer interrupt - that is used to check (detect) for a signal (through the ADC) at a prescribed rate. The rest of the peripherals

(such as USB, SPI memory writes and RS232) won't get executed until (after) that event occurs, where I would have to stop just timer 6 and change speed, then restart the needed interfaces.

[Tesla DeLorean]

Posted on May 08, 2015 at 21:45

One of the easier routes might be to drop the APB clocks to some minimum you need for baud rate, timers, etc.

Then increase/decrease the CPU clocking, and adjust the APB so they remain consistent.

[Rogers.Gary]

Posted on May 09, 2015 at 01:52

also sounds like a plan to try, thanks!

I've seen various documents on power consumption, but none that really spelled out specifics with respect to clock and/or bus speed.

In your experience, and given the suggestion you (and DA) provided, what kind of power saving (range) could be expected ?

I would think there's no direct proportional relationship between clock speed and power consumption...or is that a bad assumption?

[Tesla DeLorean]

Posted on May 09, 2015 at 05:30

Well tight loops with while(1); can be real killers.

It's usually all the things you have attached/interfaced to the system that pull the most power. So you really have to measure and think about things at a system level, than worry about the uA/MHz quoted in the data sheets.

CMOS gates draw current when there states change, so most current is seen as it clocks, and the more rapidly it clocks, the more things change.

[Rogers.Gary]

Posted on May 09, 2015 at 06:41

Ok, now I get it...I'll change all those ''while(1)'' to ''while(0)''

not sure it will make a lot of difference but will keep everyone posted  8=}

(thanks clive1)