migration problem 18f4450 => 18f4620 re PLL

[crystal_lattice]

Hi there, just in a nut shell (well a lengthly explanation will be welcome..) why does the PLL frequency setup differ between the 4450 and 4620? I have a running example with a 20MHz xtal on the 4450 and a running eample on the 4620 running on an 10MHz xtal but the 4450 PLL is set to x5 and the 4620 is set to x4. How does this work?

I have working code to measure frequency (5KHz to about 500Khz) running on the 4450 but need to change to 4620 and am concerned with the impact it will have on the min/max frequency capability of the ccp, especially since the xtal will be different.

thanx in advance

here is the code portion of the working 4450:

[Ttelmah]

The 'standard' 18 chips, have a single PLL, giving *4 frequency multiplication, that is configured either via the fuses, or in some cases is software selectable. This is what you have on the 4620. Hence with a 10MHz crystal, and this enabled, the chip clocks at 40MHz.

The USB chips, instead have a fixed *24 PLL, and a programmable _divider_ feeding this. Just to annoy everyone, because the divider feeds the PLL, it is referred to using a 'PLL' fuse (though the fuse actually controls the divider, _not_ the PLL). This then sets the divison ratio used _before_ the PLL. To use USB2, the output frequency of this PLL, _must_ be 96Mhz, so the input frequency, needs to be 4MHz.

In your case, the 20MHz clock, is then divided by 5, to give 4MHz, which is fed to the USB PLL, which then generates 96MHz. The outut of this PLL, is then divided by two (this is done to ensure that the resulting waveform, has a symmetrical mark/space ratio), and fed to the USB circuits.

The CPU, can be fed from four sources on these chips. If 'HS' is selected, the PLL _still runs_ (unlike the 4620), but the CPU is fed from the crystal, and not from the PLL. Or the CPU can be fed from the PLL output using the 'HSPLL' clock, or the CPU can be fed from the internal oscillator, or the CPU can be fed from the secondary oscillator. In each case, the PLL still runs, and feeds the USB (the one exception, is if the 'USBDIV' fuse is turned off, which then feeds the USB directly from the master clock. This mode can one be used for 'slow speed' USB operation, and the clock must then be 6MHz.

Now, the selected CPU clock, can then be fed to another divider. In your case, CPUDIV1, which feeds the 48MHz signal to the CPU. You could select CPUDIV2, and get half the frequency, and so on.

So the big difference on these chips, comes from the need to develop a 96MHz signal for the USB, which has to happen, whatever clock is being used for the CPU. Unlike the non USB chips, the designers have therefore left the PLL permanently enabled, and allowed you to chose a number of dividers to feed it, and a number of dividers to feed the CPU clock from this. This brings both a huge amount of extra flexibility, but also loses some abilities. So (for instance), you can run the unit at 48MHz CPU frequency, from any '4MHz' multiple input frequency up to 24MHz (and from 48MHz). However you can't run at 40MHz, except from a 40MHz oscillator. There are a total of four separate programmable dividers in the clock for this unit, and four 'routing' gates controlling the sources chosen....

Best Wishes

[crystal_lattice]

Thanx Ttelmah, that explains alot, i would assume without consulting the datasheets that the usb enabled chip will also draw more power since the PLL is always running?

Just to clarify then - the 4450 timer will increment at the 20Mhz crystal rate (1/(20Mhz/4)) and the 4620 at 1/(10MHz/4)? and not at the final PLL rate=> 48Mhz (4450) and 40MHz(4620)?

It seems when doing a simple experiment with my signal gen attached to the pic that i can measure lower frequencies? is this correct, for some reason i thought it would be the opposite, higher clock = higher frequency limit

am i correct in saying this??

[Ttelmah]

The timers alll feed from the CPU clock (as opposed to the USB clock). If you select 'HS' as opposed to 'HSPLL', the timer will run from the 20MHz source. With HSPLL, it should be running from the 48MHz. If you look at the clock diagram (figure 2.1),the timers feed from the 'peripheral' clock (about 2/3rd way down on the right hand side).
You should see the lowest frequency supported rise with the faster clock. If not, double check what clock rate the CPU really is running at (generate a simple square wave, and time it). Remember if you are using an ICD, that changes to the PLL, do not occur till after a reboot. You don't actually tell us which timer you are using to measure the frequency, so we can't really comment o what you are seeing....

Best Wishes

[crystal_lattice]

Sorry, its timer1 and the CCP is set to trigger on each 16th rising edge, the icd is not involved in anything. Will have to setup the scope to check the square wave, though the uart works with the delay set for 40Mhz/48Mhz.

Ive done a quick check: on 4450@48Mhz the timer1 count = 64714 @ 2.96690Khz(f was calculated by pic),

on 4620@40MHz the timer1 count = 53923 with f= 2.967194(calculated by pic, but same on f gen)

pretty confusing??

[Ttelmah]

The faster chip did _more_ counts. 64714, versus 53923. Ratio 1.200:1.
Nearly what would be expected.
However the value is further adrift than you'd expect for the number of counts performed. I'd be checking the capacitance loading on the 20MHz crystal. It looks as if it is running at about 1.0001* it's expected frequency. Now the old code giving the 'right' answer, is a 'fluke' (your actual measurement accuracy for a single measure, cannot exceed 99.9963%, given the clocks being asynchronous - hence the possibility of taking one more, or one less edge from the measuring clock, and the number of edges being counted). Whether this answer is 'right', also depends on the calibration accuracy of the frequency generator - unless it has been recalibrated recently, the last couple of DP, are spurious.
Remember a typical 'off the shelf' crystal, will only give you about 1 part in 10^5 accuracy, and only this if the loading capacitance is right (remember to factor in the board capacitance and pin capacitance). The third overtone crystals normally used, are quite sensitive to load capacitance.

Best Wishes

[crystal_lattice]

Thanx again Ttelmah for such an in depth explanation!! The crystal loading cap's are on my dev board and i use different crystals with same caps, so this could very well be the problem, the frequency gen has not seen a calibration in more than 5 years since i've had it and it is second hand, it is an Philips analogue... and the output is very close to what i've calculated so i'm happy. This is a project for university so a few beats off from the crystal wouldn't kill anybody...

I was however wondering the other day where i could find some help/info regarding the calculation of frequency drift on a 555 astable (or other components for that matter) with respect to temp and how to correct it given a temp reading. Could you perhaps steer me in the right direction, since you seem to have a profound knowledge regarding these things.

Regards

[Ttelmah]

Your problem is almost certainly not the 555 (especially if you are using one of the 'newer' variants), but the components round it.
Start with the chip data sheet. This gives the _chips_ drift with temperature and voltage changes (you need to factor the later in, since the voltage regulator will also have a temperature drift...). Some of the newer 'equivalent' chips have temperature drifts as low as 0.005%/C. Then you need to look at the drift for the resistors, and (probably the main problem), the capacitors. For really good stability, mica is probably the 'best', but expensive, and bulky. Polystyrene, is the 'second choice', and for good value, small sizes, without too much drift, look at polycarbonate. Many common capacitors, have temperature coefficients over 0.1%/degree (C)....
If you look at the formulae for the chip, giving how it's frequency shifts for given component value changes, you can use the component drift, to calculate the resulting drift from the oscillator.
Now, the really 'ingenious' bit, comes when you chose (for example), a capacitor, whose drift is the opposite polarity to that expected from the resistors and the chip itself. With 'care', you can get much better stability than might be expected.

Best Wishes