Internal 31khz oscillator problem

[a.g.electronic96@gmail.co]

I have a PIC18F24K20. I am trying to run the internal 31khz Lp oscillator.
But its not running, I have written a simple program to blink an LED on RA0 pin to test the timing and also operation of internal 31Khz oscillator.
But the pic is not working at 31 khz because the timing of led is not correct. the program is : (I am programming by CCS C ver1.30 )
when I am executing program by #use delay(clock=8000000) the chip works fine... I need some advice or if you could please post the setting to run internal OSC 31khz.

[Mike Walne]

You don't tell us what the timing error is.

You don't tell us either, how you measured the LED frequency, or what you expected to get.

I don't have your PIC so I've just tried with a 18F1320, in MPLAB prior to burning a REAL device.

MPLAB is giving me 20 instruction cycles per loop. or ~2.58ms per loop.

This is close to what I would expect.

How does this compare to what you've observed?

Mike

I don't recognise your compiler version.

[Ttelmah]

You do understand how inaccurate that clock is?. The LFINTOSC, is only specified as +/-15% accuracy. Given also that at this low frequency, the output instructions and loop jump, will take well over half a mSec, the loop could easily be up to nearly 4mSec long!....

Best Wishes

[Mike Walne]

OK.

I've had time to get my 'scope out.

I've measured:-

1) Mark = 1477us
2) Space = 1209us
3) Period = 2686us

That's consistent with:-

a) Clock frequency 29.85kHz, i.e. 134us per instruction cycle.
b) 7 instruction cycles for each delay, i.e. 938us
c) 2 instruction cycles for each port write
d) 2 instruction cycles for loop operation

My clock was on the slow side.
Theoretically the instruction cycle should be 7.75 per ms.
That's nearer to 8 rather than the 7 which my compiler used for the delay_ms(1).
Maybe it would be better to use delay_cycles(xx) to force things along.

Nevertheless I'm happy with my measurements.

Mike

[rikotech8]

I want to ask Mike Walne, how did you find out how many instruction cycles takes each of these: loop operation, port write etc...? In other words, for example, how can I find out how many instruction cycles would take an command like output_toggle(), if we have STANDARD_IO declared.
_________________
A person who never made a mistake never tried anything new.

[Ttelmah]

1) Look at the .lst. Count.
2) Larger bits of code, use MPLAB, and it's internal SIM, 'stopwatch' feature.
3) Even larger stuff, trigger an output pulse before and after the code section, and time it.

Mike used number 2 for his original comment.

Best Wishes

[jeremiah]

To the OP:
There are two registers that you have to set to use the 31k, which you are not currently doing. For 31kHz, you do have two options, you can divide it down from the high freq internal oscillator (which might be more accurate..check the data sheet to see) or get it straight from the low freq internal 31k. Either way, you need to read the Oscillator section of the data sheet for your pic. It mentions all the settings you need for 31k.

As a final note, you'll need to adjust your #use delay() as well. The clock speed will most likely not be 31000. I *think* your chip uses 31250, but check the data sheet to verify.

[Mike Walne]

[Ttelmah]

Actually the register settings default to correct for the 31K operation (I checked). If you use setup_oscillator(OSC_31250), it switches the OSCTUNE bit to select the HF oscillator, but it defaults to selecting the LF oscillator (which does give 31K - 31250, is the frequency you get when the HF oscillator is selected).

I have actually tested, and the oscillator works for me (though at very inaccurate rates - the 31250 selection is much better), on a 44K20.

He seems to have major problems getting any oscillator except faster ones to work.

The default as posted is selecting the required bits in OSCCON, FOSC, and OSCTUNE. The compiler sets OSCCON to 0, the top two bits of OSCTUNE to 0, and FOSC is in the fuses.

I must admit I'd be looking at hardware. A supply problem when current drawn is low (it declines at these low clock rates), or something similarly 'obscure'.

Another thought, not a large enough current limiting resistor on the LED. Then at high speed the faster pulse is short enough that the supply capacitance can maintain the rail, and the supply keeps working, but at the low frequencies, the supply droops and the chip stops working.

Best Wishes