dsPIC30F internal FRC oscillator & PLL

[AlastairM]

Hi,
I'm using a dsPIC30F3012 which isn't letting me use the PLL!
version 5.115

easiest program I could make:

[Ttelmah]

Key is, it doesn't like exact clock speeds!...

The compiler doesn't understand you specifying 29.48MHz.
Just say 30MHz. or 120MHz. It'll tell you what it thinks is being generated.
It thinks the internal oscillator is just on 7.5Mhz, not the 7.37MHz figure,
so can't work out how to get 29.48MHz.

It is showing FRC_PLL4 in your fuse dump though. 0701.

Are you sure there isn't a board problem (supply decoupling, smoothing etc.),
that isn't preventing the faster clock from working?.
Remember if the chip can't work at the faster rate CKFSM will make it drop
back the default 7.37MHz.....

[AlastairM]

Thanks for the quick reply...
The datasheet says:
'The FRC oscillator is a fast (7.37 MHz ±2% nominal) internal RC oscillator'
So I think I'm specifying it correctly - am I missing something obvious?
(for example if I ask for 14.74MHz the compiler complains because there's no 2x PLL)

[Ttelmah]

See the line I have added to my previous post. The compiler is setting the
chip up correctly. I think you have a hardware problem. Remember the
supply consumption shoots up as the speed increases.
There isn't a 2* PLL. Just 4, 8, 16*.

[AlastairM]

Thanks! thinking about it you must be correct. I'll check the PCB (bit more difficult with the customer's one )
I had a play:
If I ask for 30MHz the compiler gets 29922200Hz.
which is PLL x 4 with the FRC tuned up by 1.5% - sneaky.
I'll leave everything to the complier in future and think less!

[AlastairM]

I've now got an extra tant right next to the chip (it's powered by a TSR1-2433)
I have a 4-layer board with good power planes - so I think the hardware is good.
If I include the #FUSES CKSFSM then the circuit operation is as before with a mismatch of delay timing.
I tried to see the state of the OSCCON:CF flag but it looks OK

[AlastairM]

can also use '#use delay(internal=120MHz)' if I omit '#FUSES CKSFSM'
fast serial comms works OK so now I'm doubtful of the CKSFSM.
Is this one for CCS or do you have any other ideas?

[Ttelmah]

First thing. Double check the board has got all three Vdd pins and all three
Vss pins connected (including AVdd and AVss). There should be a separate
0.1uF ceramic or polyester decoupling capacitor by each of these pairs.
As close as possible to the chip.
Where does your PSU come from?. How is it decoupled?.
What the chip is exhibiting, is that the Frc oscillator is unstable, so is
triggering the FSCM. Now the commonest cause of this is instability in
the supply. Not a CCS problem, this is hardware.

Do you have a frequency meter?.
If so, enable the CLKOUT signal, and do some testing.

What is your supply voltage?.
The 4* PLL is limited if you are running at lower voltage.
Are you sure your part is the -30 variant?. Otherwise the 120MHz is
not supported.

[AlastairM]

all power supply pins and decoupling look good.
PSU good.
I don't think I can output CLKOUT.
I'll just omit the 'fail safe clock monitor' and 'clock switching' fuse since I think it's really intended for an external clock and not for an internal clock with PLL.

[Ttelmah]

It is not a software issue, so it seems rather pointless to talk to CCS.

There is one other hardware issue that could cause this. Can you check
the rise time of the supply?. You can see this if the supply has a slow rise
time, and does not meet the data sheet requirement of 0-5v in less than
0.1 seconds. The problem then is the chip starts before the supply is
at a high enough voltage to properly support the PLL. Hence FSCM triggers.

[AlastairM]

Richard from CCS had some helpful info:
(I'll do some more investigation when I get a chance...)
I reviewed what you have and it is correct to run the device at 60MHz, 15MIPS. From the testing I did here after you program it you need to power cycle the device to get it to run with the PLL enabled. This device only copies the FOS configuration bits to the NOSC bit in the OSCCON register on a POR (power on reset) or BOR (brownout reset), because of this after it's programmed it doesn't have the PLL enabled.

If you want to make sure it starts with the PLL enabled after it's programmed you can add the following call to setup_oscillator() to the beginning of main():

setup_oscillator(OSC_INTERNAL, 60000000);

If you do the above then you will need to have clock switching enabled so setup_oscillator() can do that clock switch., however the compiler should force that configuration fuses when the above call to setup_oscillator() is added.

[Ttelmah]

Good,
Glad you are moving forward.
I do suspect the supply rise time is going to be the issue. I have seen this
with some similar chips....

[AlastairM]

All working fine now!
(rise time on the 'scope is well within spec)
Just one gotcha I queried with CCS:
if the oscillator is set in the header file i.e.
#use delay(internal=60MHz)
the compiler is clever and tunes the FRC to get as close as possible to 60MHz (59.8444MHz)
if you then use
setup_oscillator(OSC_INTERNAL, 60000000); in main()
it will reset the OSCTUN to 0 giving an oscillator of 58.96MHz
this is a 1.5% error from the setting in the header (the delay() is used for baud & delays_ms)
If you want to be accurate then the original delay would have to be set to an easy to achieve value:
#use delay(internal=58.96MHz)
i.e. the 7.37MHz internal x 8 PLL and OSCTUN set to 0.
Error probably small enough to ignore?

[temtronic]

you should be fine but... for accurate timing, use a crystal/caps that's a nice 'binary' frequency, like 2.4576MHz. That way dividers give perfect timing for UARTs....