SOLVED: PLL frequency change problem

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am having problems changing the PLL frequency; search in the forum did not produce any results

 

It is running at 32MHz and I want to change it to 16MHz:

#define XTLFRQ 8000000

#define SYSFRQ 16000000

 

......

 

/* running happily at 32 MHz */

 

......

CPU_CCP = 0xd8; /* switch to internal rc */

CLK_CTRL = 0b0000;

asm volatile("nop");
asm volatile("nop");
asm volatile("nop");
asm volatile("nop");
 

OSC.CTRL =     0b00001001; /* disable pll */
OSC.PLLCTRL =  0b11000000 | (SYSFRQ / XTLFRQ);
OSC.CTRL =     0b00011001; /* enable pll */

 

while (!(OSC.STATUS & OSC_PLLRDY_bm))
    ;

 

CPU_CCP = 0xd8;   /* switch to pll */
CLK_CTRL = 0b0100;

......

Problem is it keeps running at 32MHz.    Is there more to be done than disabling it before changing?   That's all I could find in the documentation.    The nops cover the 4 clocks for source switch over.

 

Has anybody changed the PLL frequency successfully?

This topic has a solution.
Last Edited: Sun. Apr 19, 2015 - 07:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You generally start with the 2MHz RC,   start the PLL,   when the PLL is ready,   switch to the PLL,   disable the 2MHz.

 

If you want to change the PLL on the fly,   I would just switch to 2MHz,  and repeat this process.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is this from your real code?

#define XLTFRQ 8000000

// ...

OSC.PLLCTRL =  0b11000000 | (SYSFRQ / XTLFRQ);

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@david.prentice: That's what I did (see code above).    It's not working.    Have you done it?

Last Edited: Fri. Apr 17, 2015 - 08:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@snigelen: No, I typed the #defines.   Sorry, I corrected it above.

Last Edited: Fri. Apr 17, 2015 - 08:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well,   I normally run the Xmega with the PLL.     But I only set it once at startup.

And you can overclock the Xmega very easily.    e.g. 34MHz .. 40MHz.

No,   I have never attempted 'silly' clock frequencies with the PLL.

 

Why do you want to change the PLL on the fly?

My suggested sequence is exactly the same as a warm-reset.   i.e. 2MHz -> PLL

so I don't see why you can't change backwards and forwards during an application.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
Well,   I normally run the Xmega with the PLL.     But I only set it once at startup.

So do I.   Until now.

david.prentice wrote:
Why do you want to change the PLL on the fly?

I had expected this question.   One possible answer is that I have nothing better to do with my time on a Friday night and I said to myself: why not make my life more interesting and try to change the PLL frequency on the fly just for fun.

david.prentice wrote:
My suggested sequence is exactly the same as a warm-reset.   i.e. 2MHz -> PLL

so I don't see why you can't change backwards and forwards during an application.

The clock source switch does not seem to be the problem.   It's the PLL factor change.

 

Could you have a look at the code if that matches the sequence you would expect to work?   Because the code does not.

Last Edited: Fri. Apr 17, 2015 - 08:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not tonight.

 

If you post buildable code,   I will run it tomorrow.

 

The snippet in message#1 would be easier to read if you used the standard bitmask names.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Highly unlikely that I am the first person trying to change the PLL frequency.   And with a very high probability there is a person on this very forum that did it with more success.   Any hint / help would be appreciated.

 

@David: no point tyring the code above, I know it is not working.    You are certainly right about increasing readability using the correct bit names but in this case the code is in a hardware driver; I have to look at the data sheet anyway so I found it more efficient to simply type in the bit pattern.   The code will never be looked at again and for another (non-xmega) processor the hardware drivers are rewritten anyway.    I do not get more money using the bit names but it certainly does cost me more time.

Last Edited: Sat. Apr 18, 2015 - 08:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is my bedtime now.     I will experiment tomorrow morning with changing PLL.    (and using standard bitmask names)

 

I have a 32A4U and a 128A1.     AFIK,   the PLL should work the same with both families.

 

David. 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi David,

 

no need, code above works, just tested it again.    Don't know what I tried at the time, was probably working a bit too long.   Or the lock bit had been set in the application code.    The nops are not required either; I still left them in.

 

Apologies for wasting your time.

 

Regards,

Last Edited: Sun. Apr 19, 2015 - 07:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Correction: the nops are required on a cpu with date code au1406.   On a cpu with date code au1345 it works without the nops.

 

So I would say the nops are required (probably only 1 or 2) for the cycles to switch over the clocks; I'd say PLL cannot be disabled when still running from it (for 2 clocks).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 I'd say PLL cannot be disabled when still running from it (for 2 clocks).

Why would you ever want to do that?  If you disable the only active clock the processor comes to a grinding halt!

 

From the AU Manual:

 

It is not possible to select a non-stable or disabled oscillator as the clock source, or to

disable the oscillator currently used as the system clock source.

 

JC

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is out of context.   You should read the posts from the beginning.   We did not talk about disabling the active clock source.  

 

AU manual says PLL has to be disabled before the values can be changed and after the clock source switch instruction it will run for two clocks on the old and then for two clocks on the new.   So it seems the nops are required because the manual does not say if the cpu is stopped during that time and my test showed that at least one cpu is not working without the nops.

Last Edited: Sun. Apr 19, 2015 - 08:16 PM