PIC oscillator frequency quite low

[MrAl]

Hello,

After programming a 16F684 PIC chip with two delays of 0.001 seconds
(1ms each) and having it set and reset port pins, the measured frequency
on each pin should have been 500Hz exactly with a clock of 4MHz
(the two delays run one after the other then repeat).

Instead, the frequency at both pins measured 445Hz.
I thought it might be the freq meter, so i used one that i built myself
that uses a precise internal crystal osc to gate the signal, but this
also measured low: 444Hz.

I went over the loop timing and it looks accurate, and i have tested
other similar loops using a special simulator that counts clocks
and all that looks accurate.

Reading the data sheet i find there is a value called "OSCTUNE"
which adjusts the oscillator up or down depending on the value
in this register. Reading more, i found that the factory tuned
oscillator is supposed to be 8MHz when OSCTUNE is exactly 0,
so i set this to zero...still same error in frequency...444Hz.

Ok, so the question is, what would be the accuracy that should
be expected in the clock then? The above numbers suggest that
it is quite a bit off, more than 10 percent low when OSCTUNE=0,
which doesnt sound right. I thought they were able to get these
on chip osc's accurate to 1% right?

Any ideas or suggestions?

Also, what would be the long term expectancy on the clock accuracy...
if i set the loop to be 500Hz now (today, using a different count value)
what will it be 10 years from now?

[bodgy]

Al,

Are you using interrupts?

It might be down to the oddity of the 4 cycle access. I'm not talking about cycles as in instruction count, but in the 4 periods that count towards the 1 cycle instruction time.



Is the input frequency bang on, if you are using a crystal or resonator try fiddling with the cap values.

I've just read the errata there looks as though there is a glitch if your using the CCP.

[MrAl]

Hi Bodgy,

No, not using interrupts yet. That vector is set to 'return' too.

What do you mean by the oddity of the 4 cycle access?
From what i read, it says that the 8Mhz internal osc is set
to divided by 2 (via a register) which gives a 4MHz osc,
which gives a 1MHz instruction clock (1us per instruction clock).

There is no input frequency because it's using the internal 8MHz
clock, which is 'supposed' to have an accuracy worst case of
+/- 5 percent. Here it is -12.6 percent (with OSCTUNE=0).

Im not using CCP or anything else. I have everything turned off.
All this program does is output a pulse on two pins, 180 degrees
out of phase with each other. It's a square wave, 0.001 sec on
and 0.001 sec off (both pins but out of phase).
I just double checked the timing again with my timing simulator,
and it shows exactly 1000 counts per delay code section, which
is dead on perfect.

I hate to think that when they spec the clock accuracy they are talking
about how well it can be user calibrated, as in after the OSCTUNE is
set up. If i set OSCTUNE for the lowest possible value, the frequency
comes in at just -2.88 percent off. This would be within the 5 percent
spec, but that would be silly. I would expect it to be within 5 percent
with OSCTUNE=0 so that the user can calibrate it closer to 0.00 percent
if needed.

I couldnt find anthing about the long term stability either. This would be
very nice to know, as it would dictate whether or not some apps really
*need* to have an external crystal oscillator or not.
A comm port for example might run ok for 5 years, then on the 6th year
if the frequency goes off by too far it might not work anymore
I'd have to know this info, or else i'd have to default to always using
an external crystal oscillator for those kinds of things.

Any help, ideas, or places to look would be appreciated, and TIA.

BTW, where did you find the errata sheet on this chip? Thanks.

[dyarker]

Sounds like Al is using the internal oscillator.

[JPKNHTP]

-JPKNHTP

[MrAl]

Hi again,

Well, the OSCTUNE reg isnt the same as the OSCCAL reg, which i think
is the register you are thinking of. The OSCCAL reg in some devices
is factory set, but the OSCTUNE (apparently in other devices) is to
be set to b'00000000' unless you want to change the osc frequency.

I just did a real simple test to see what is going on here. I used
a very simple loop that takes exactly 10 clock cycles and puts out
a square wave on one of the ports. As it turns out, with OSCTUNE=0
the output frequency is down by a factor of 0.83 so it's almost 20
percent off. Setting OSCTUNE as low as possible (for max freq)
the frequency of the square wave is off by a factor of 0.93, meaning
it's a little better but still not that great.

BTW this chip isnt spec'd at 1% like some of the other chips, it's spec'd
at 5%, but even that isnt anywhere near what im seeing.

I guess i'll have to resort to using a crystal when i need good frequency
set points or very good long term stability.

I have yet to test one of the 1% spec'd devices though, maybe they
will turn out to be better.

[JPKNHTP]

-JPKNHTP

[MrAl]

Hi again Jpknhtp,

Actually OSCCAL is not the same thing as OSCTUNE.
OSCCAL (on devices that have that) is supposed to be set by a value
that has already been determined by the manufacturer to get
the internal osc to a value that is close to what it is supposed to be.
This value is obtained by doing a call to location 0x3FF on the 12F675
device. On some other devices, they use OSCTUNE, which has no
value set by the manufacturer (other than zero). In other words,
it's like devices with OSCCAL have a value which you must
first retrieve and then set, but with devices with OSCTUNE you always
set to zero unless you want to adjust the freq up or down for some
app. Supposedly, the device with OSCTUNE is already factory set
at the correct frequency when OSCTUNE=0, whereas devices with
OSCCAL might have a value of 80, 8C, or something else stored
at location 0x3FF (in a returnw statement) that you retrieve and then
use to set OSCCAL. If you dont set OSCCAL the freq will be off, but
supposedly if you dont set OSCTUNE (allow it to be zero) the device
is supposed to be on frequency. As i found how, however, it doesnt
seem to work quite that accurately though. In fact, as i said, it's still
off by some 7 percent even with OSCTUNE set at it's lowest value
(which is best for that particular chip itself). Perhaps another chip
would be closer, it's just this one i guess, or maybe this is typical
(the data sheet isnt that accurate).
I'll have to look for the errata sheet next.


Supposedly yes it should work like that: you should get around say
1000Hz output and then you tune OSCTUNE to get closer.
With my particular chip, i would have to set the delays based on a
much lower frequency than should be encountered with a 5% tolerance.
Strange.
I can still use the chip, but will have to calculate the delays using instead
of 1MHz clock i'll have to count on a 930kHz clock (with OSCTUNE set
for max freq).


Other aspects of the chip seem to work ok i guess.

[philba]

the internal oscillator is dependent on a number of things including temperature and voltage. The 5% number is based on very specific criteria. I would recommend you NOT use intosc for any application with critical timing.

[Robert Reed]

MrAl
just a thought, but have you tried inputting an accurate external clock to see if that clears uop problems?

[bodgy]

That 1uS instruction time is split up into quarters - one of the reasons for the Pics inherent problem with RWM instructions. It is also a gotcha when timing things using the timers, especially 16 bit timers such as timer1.

If you use a Brezenham algorithm for timing the jitter will be greatly reduced - naturally my website has the details as does the originator of the code on the piclist.

The quarter cycle times is demonstrated in the mammoth mid-range manual for uChip.


Colin

[MrAl]

Hi again,

Philba:
Well i have a supply of 5.06v so i thought that would be ok
for the osc. You see any problems with that?

Robert:
Oh yes good idea. I'll have to pic (pun) up an oscillator
for testing with. Should be easy to do too.
I have some high freq ones laying around somewhere
but they are 50MHz and up. Also have a 2MHz somewhere
but i'd have to find it. I'd like to use 8MHz for this.

Bodgy:
Im still not sure i know what you are talking about here.
I thought that (on this part) the 8Mhz clock was div by 2
(with software) which gave a 4Mhz clock (like other devices
already have) and that 4Mhz clock is div by 4 to produce the
instruction clock, which is 1us.
Another point is that the super simple timing code i used
for that last test has no read/modify/write cycles at all.
Here is the code:

Code: Select all

  bcf PORTA,5
loop
  bsf PORTA,4  ;1
  nop          ;1
  nop          ;1
  bcf PORTA,4  ;1
  goto loop    ;2

Total loop clocks=6

The nop's are there just to keep a 50 percent duty cycle.

I got all the instruction times from the manual.

Do you see any problem with this short code block?

[MrAl]

Hi again,

No ideas here? Note that short block of code should time as per
manual, because the read/writes are contained within the 4 clocks
which make up one complete 1MHz instruction clock.
The numbers to the right of the instructions are the clocks that
that instruction takes up (1 instruction clock takes 1us the way i have it
set up in the config for the oscillator, that way it's the same with several
device part numbers...some that run at 8MHz and some that run at
4MHz).

It's hard to believe the osc is off by this much because the data sheet
says 5 percent. Should i expect the other part numbers to be off
by this much too? Some spec 1 percent, yet others spec 1 percent
but they include the OSCCAL value. I just dont want to buy parts
that are spec'd at 1 percent and find out they are much more ha ha.

Any ideas appreciated...and thank you very much in advance!
BTW, i really do appreciate any replies i get, even if they dont
work out in this exact application because sometimes they point to
something else which helps in another application...at least i have
found this to be the case in past web message board experience.
So efforts are not wasted in most cases.

[ecerfoglio]

I don’t know if it is the case with Pics (as I worked programming the "old" Motorola's MC 68705 series some time ago - Yes, it was still called Motorola ), but there may be some "hidden" instruction cycles like interrupt services (even internal interrupts like timers, watchdog, etc).

If you want to set a known frequency the best way may be to use a timer interrupt and to set (or reset) your output pin in the interrupt service routine.

If you do more than one thing in the interrupt service routine, the “critical timingâ€

[philba]

Unless Al enabled interrupts, his cycle timing should be a true reflection of the processor speed and thus Fosc.

Like I said before, I wouldn't count on an intosc osc for timing. I personally wouldn't rely on any internal osc for timing. a crystal and couple of caps are fairly cheap.

On your code, Al, it looks ok - I assume that isn't the 500 hz code.

the end of the day, it is what it is and you should design your code to deal with it. However, note that this is one chip, if you are creating a product, you will need to characterize a broader sampling. what you may be seeing is a process variation.

Phil

edit: by the way, for any lengthy timing, using a timer is a far superior solution.