View previous topic :: View next topic |
Author |
Message |
AlastairM
Joined: 28 Apr 2008 Posts: 28
|
dsPIC30F internal FRC oscillator & PLL |
Posted: Wed Jul 19, 2023 6:39 am |
|
|
Hi,
I'm using a dsPIC30F3012 which isn't letting me use the PLL!
version 5.115
easiest program I could make:
Code: |
#include <30F3012.h>
#device ICSP=1
//#use delay(internal=29.48MHz)//tried here to force PLL on in hardware
#FUSES NOWDT //No Watch Dog Timer
#FUSES CKSFSM //Clock Switching is enabled, fail Safe clock monitor is enabled
#use delay(internal=29.48MHz)
#define LED PIN_B7
#define DELAY 500
|
Code: |
#include <test dsPIC30F3012.h>
void main()
{
while(true)
{
output_low(LED);
delay_ms(DELAY);
output_high(LED);
delay_ms(DELAY);
}
}
|
with 'internal=7.37MHz' I get a 1s Flash - perfect!
with 'internal=29.48MHz' I get a 2s Flash
with 'internal=117.92MHz' I get a 16s Flash
looking at the fuses:
Code: |
#use delay(internal=7.37MHz)
F80000: 00FF0100 00FF003F 00FF87B3 00FF310F
F80008: 00FF330F 00FF0007 00FFC003
#use delay(internal=29.48MHz)
F80000: 00FF0701 00FF003F 00FF87B3 00FF310F
F80008: 00FF330F 00FF0007 00FFC003
|
Does anyone have any ideas?
Thanks Al |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Wed Jul 19, 2023 7:06 am |
|
|
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.....
Last edited by Ttelmah on Wed Jul 19, 2023 7:17 am; edited 1 time in total |
|
![](templates/subSilver/images/spacer.gif) |
AlastairM
Joined: 28 Apr 2008 Posts: 28
|
|
Posted: Wed Jul 19, 2023 7:13 am |
|
|
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) |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Wed Jul 19, 2023 7:20 am |
|
|
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*. |
|
![](templates/subSilver/images/spacer.gif) |
AlastairM
Joined: 28 Apr 2008 Posts: 28
|
|
Posted: Wed Jul 19, 2023 7:48 am |
|
|
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! |
|
![](templates/subSilver/images/spacer.gif) |
AlastairM
Joined: 28 Apr 2008 Posts: 28
|
|
Posted: Wed Jul 19, 2023 9:03 am |
|
|
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
Code: | #BIT GONEWRONG=0x0742.3
...
while(GONEWRONG)
{
(do a different flash)
}
|
(did I code that correctly?)
If I don't include #FUSES CKSFSM
then the LED switching rate is 1s (as expected) |
|
![](templates/subSilver/images/spacer.gif) |
AlastairM
Joined: 28 Apr 2008 Posts: 28
|
|
Posted: Wed Jul 19, 2023 9:33 am |
|
|
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? |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Thu Jul 20, 2023 12:25 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
AlastairM
Joined: 28 Apr 2008 Posts: 28
|
|
Posted: Thu Jul 20, 2023 4:58 am |
|
|
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.
Quote: | For the purpose of clock switching, the clock sources
are sectioned into four groups:
• Primary (with or without PLL)
• Secondary
• Internal FRC
• Internal LPRC
The user can switch between these functional groups
but cannot switch between options within a group. |
Since I can use the UART at 115200 with no corruption and I only need to operate at 19200 I'm happy to proceed.
Thanks for your help! (I'll contact CCS anyway but I haven't got time to wait for a reply...) |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Thu Jul 20, 2023 5:30 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
AlastairM
Joined: 28 Apr 2008 Posts: 28
|
|
Posted: Tue Jul 25, 2023 1:44 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Wed Jul 26, 2023 1:13 am |
|
|
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.... |
|
![](templates/subSilver/images/spacer.gif) |
AlastairM
Joined: 28 Apr 2008 Posts: 28
|
|
Posted: Wed Jul 26, 2023 10:41 am |
|
|
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? |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9168 Location: Greensville,Ontario
|
|
Posted: Wed Jul 26, 2023 5:35 pm |
|
|
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.... |
|
![](templates/subSilver/images/spacer.gif) |
|