Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

Changing CCLK on the fly and keeping peripherals happy

Changing CCLK on the fly and keeping peripherals happy

2005-05-26 by Brett Delmage

Does anyone have experience with dynamically controlling CCLK and 
keeping clocked peripherals like timers and UARTs operating nicely?

I want to run at only slower speed (10 MHz) for now. In the future when 
I have heavier CPU needs (e.g. encryption) I would like to dynamically 
increase CCLK only when it is required. I don't have the power budget to 
run fast all the time.

Consider the simple case of going from 10 MHz (crystal) to 60 MHz (PLL 
enabled) with PCLK at 1/4 CCLK while the system is in operation.

These are the steps I think are required to do this correctly:

Configure PLL for 60 MHz CCLK.
Wait for lock.
Reconfigure MAMTIM to increase # Flash access cycles.
Reconfigure External memory control BCFGn to increase cycles for memory 
access.
Reconfigure timer prescalers
Reconfigure UART divisor latches (multiply by 6)
Select PLL clock.

To return to 10 MHz:
Select direct clock (10 MHz)
Reconfigure timer prescalers
Reconfigure UART divisor latches (multiply by 6)
Reconfigure MAMTIM to decrease # Flash access cycles.
Reconfigure External memory control BCFGn to decrease cycles for memory 
access.

There is obviously going to be some timing error in the timers and the 
UART clock but I think it should be minimal. I don't see any side effect 
if there is no activity at the time of CCLK change. Do you?
If the UART is actively receiving or transmitting at the time of CCLK 
change I imagine a character could be scrambled. I'm not sure it would 
be though.

SPI should run fine with a clock speed change in the middle of a 
transaction, correct? (providing that minimum times are respected)

Does this make sense? Can it work? The only PCLK-dependent devices I am 
using are timers and a UART. I am not using CAN.

Has anyone done dynamic clock changing like this, successfully or not?

In any case, I'll share my experience here, good or bad, when I have it.
Thanks for your ideas.

   Brett

Re: [lpc2000] Changing CCLK on the fly and keeping peripherals happy

2005-05-27 by Robert Adsett

At 04:04 PM 5/26/05 -0400, Brett Delmage wrote:
>Does anyone have experience with dynamically controlling CCLK and
>keeping clocked peripherals like timers and UARTs operating nicely?
>
>I want to run at only slower speed (10 MHz) for now. In the future when
>I have heavier CPU needs (e.g. encryption) I would like to dynamically
>increase CCLK only when it is required. I don't have the power budget to
>run fast all the time.
>
>Consider the simple case of going from 10 MHz (crystal) to 60 MHz (PLL
>enabled) with PCLK at 1/4 CCLK while the system is in operation.
>
>These are the steps I think are required to do this correctly:
>
>Configure PLL for 60 MHz CCLK.
>Wait for lock.
>Reconfigure MAMTIM to increase # Flash access cycles.
>Reconfigure External memory control BCFGn to increase cycles for memory
>access.
>Reconfigure timer prescalers
>Reconfigure UART divisor latches (multiply by 6)
>Select PLL clock.
>
>To return to 10 MHz:
>Select direct clock (10 MHz)
>Reconfigure timer prescalers
>Reconfigure UART divisor latches (multiply by 6)
>Reconfigure MAMTIM to decrease # Flash access cycles.
>Reconfigure External memory control BCFGn to decrease cycles for memory
>access.

No experience, but a thought or two.  I'd want to turn off interrupts and 
re-init the peripherals across the clock changes.  There's a good chance 
they would get confused (even the A/D).

>There is obviously going to be some timing error in the timers and the
>UART clock but I think it should be minimal. I don't see any side effect
>if there is no activity at the time of CCLK change. Do you?
>If the UART is actively receiving or transmitting at the time of CCLK
>change I imagine a character could be scrambled. I'm not sure it would
>be though.

Activity on UART during transition could very well confuse things, possibly 
for more than one character if the change is in the right direction, same 
for CAN etc...

>SPI should run fine with a clock speed change in the middle of a
>transaction, correct? (providing that minimum times are respected)

Hmm, that might actually make it through OK, but it is still possible that 
timer glitches might mess it up.  Now if there was a note in the user 
manual or data sheet indicating that the peripherals were safe during the 
transitions that would be another matter but I don't remember there being 
any such note.

>Does this make sense? Can it work? The only PCLK-dependent devices I am
>using are timers and a UART. I am not using CAN.
>
>Has anyone done dynamic clock changing like this, successfully or not?
>
>In any case, I'll share my experience here, good or bad, when I have it.
>Thanks for your ideas.


Looking forward to it.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.