Post by thread:[PIC]: Clock skipping seconds?

Hi, I've written some code that's supposed to keep track of the number of minutes that have passed since the device was powered up. Unfortunately, it seems to be missing roughly one second every minute. I've uploaded the code to <http://www.philpem.me.uk/pic/> - if anyone can see what I've done wrong, please let me know :) The target device is a PIC18F252-I/P running from a 4MHz crystal. The T1OSC crystal is a 32.768kHz watch crystal with 2x 22pF load capacitors (one on each leg, connected between the crystal and ground). I've checked the LED_PIN output on a scope - the gap between the pulses is exactly one second (there's also another file - MAIN.ASM - there's nothing in there besides the reset vector, a CALL to ISR_INIT and a loop that checks FLAG_MINUPDATE, waits a few mS and then turns off the LED). CONST.INC contains the timer setup constants - ISR.INC is the interrupt handler. Thanks. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, spam_OUTphilpemTakeThisOuTphilpem.me.uk | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.me.uk/ | 48xCD, ARCINv6c IDE, SCSI ... Law of Insurance and Taxes - Whatever goes up, stays up.

Phil, I don't know if this is your problem or not, but look into different values for you T1OSC capacitors. Page 109 of the datasheet (DS 39564B) is a bit vague but it does say to use "33pf as a starting point in validating the oscillator circuit". Cheers, Andrew ---- On Fri, 31 Dec 2004, Philip Pemberton (.....philpemKILLspam@spam@dsl.pipex.com) wrote: The target device is a PIC18F252-I/P running from a 4MHz crystal. The T1OSC crystal is a 32.768kHz watch crystal with 2x 22pF load capacitors (one on each leg, connected between the crystal and ground). ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag

39pf is my standard value for tuning fork "crystals". 22pF is low. --Bob Andrew Kieran wrote: {Quote hidden}>Phil, >I don't know if this is your problem or not, but look into >different values for you T1OSC capacitors. Page 109 of the >datasheet (DS 39564B) is a bit vague but it does say to >use "33pf as a starting point in validating the oscillator >circuit". > >Cheers, >Andrew > > >---- On Fri, 31 Dec 2004, Philip Pemberton >(philpemKILLspamdsl.pipex.com) wrote: > >The target device is a PIC18F252-I/P running from a 4MHz >crystal. The T1OSC crystal is a 32.768kHz watch crystal >with 2x 22pF load capacitors (one on each leg, connected >between the crystal and ground). > > >________________________________________________ >Get your own "800" number >Voicemail, fax, email, and a lot more >http://www.ureach.com/reg/tag > > -- Note: Attachments must be sent to .....attachKILLspam.....engineer.cotse.net, and MAY delay replies to this message. 520-219-2363

> seems to be missing roughly one second every minute I think you need to define exactly what's happening. "roughly" is too vague for debugging. You could try a few things - time the interval with another device (eg a PIC) - see how much time it loses over a long period. This may (or may not) reveal that it's counting something like 59.x second minutes or 59m59s hours - put pin markers in the code, for example at specific counts or when you expect something to happen

In message <00f201c4efd7$c4c99990$89aafea9@ivp2000> Jinx <EraseMEjoecolquittspam_OUTTakeThisOuTclear.net.nz> wrote: > - time the interval with another device (eg a PIC) Done that - I've checked it against a stopwatch, then checked the 1pps output with an oscilloscope. > - see how much time it loses over a long period. This may > (or may not) reveal that it's counting something like 59.x > second minutes or 59m59s hours OK, I'll try that. It seems to be counting 58 => 59 => 00 => 01, which matches the behaviour of the watches I checked it against. Thanks. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, philpemspam_OUTphilpem.me.uk | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.me.uk/ | 48xCD, ARCINv6c IDE, SCSI ... LOTUS - Let Only The Users Suffer

> > - time the interval with another device (eg a PIC) > > Done that - I've checked it against a stopwatch, then checked the > 1pps output with an oscilloscope If you're comparing the seconds output of the PIC to a stopwatch, at some point you must realise that it's lost a second. So how does that come about ? Do they start in synch and gradually drift apart or does the PIC match the stopwatch but the minute rollover is early ? Which ever happens is a great big hairy-arsed clue

In message <010401c4efdd$fe5ac930$89aafea9@ivp2000> Jinx <@spam@joecolquittKILLspamclear.net.nz> wrote: > If you're comparing the seconds output of the PIC to a stopwatch, > at some point you must realise that it's lost a second. So how does > that come about ? I usually set the stopwatch going at the same time as the PIC, then stop both when the PIC has counted a full minute. At that point, the stopwatch ends up indicating 59 seconds while the PIC is showing a full minute. > Do they start in synch and gradually drift apart > or does the PIC match the stopwatch but the minute rollover is early ? I've just checked again - the minute rollover is fine, which leaves the oscillator. What's really annoying is that the osc measured fine on a frequency counter (said FC was probably loading down the xtal just enough to make it work)... Now I get to try and find somewhere that sells 33pF caps and happens to be open today :-/ Later. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, KILLspamphilpemKILLspamphilpem.me.uk | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.me.uk/ | 48xCD, ARCINv6c IDE, SCSI ... SSC : Spare any Small Change?

> I've just checked again - the minute rollover is fine, which leaves the > oscillator. What's really annoying is that the osc measured fine on a > frequency counter (said FC was probably loading down the xtal just > enough to make it work)... I'm not convinced that's the answer. 1 second fast is too much of a coincidence and if it were me I'd let it run for 10 minutes to see if it ends up 10 seconds fast. If it really is exactly 10 seconds fast then I'm sure it's a counting error. The other thing is that you're thinking the oscillator is running at 33.323kHz or nearly 17000ppm fast. I find that hard to believe for a crystal, especially as the frequency counter indicates it's running at the correct speed. Loading the crystal I would assume would slow it down if anything, not speed it up

> the oscillator is running at 33.323kHz or nearly 17000ppm fast. I find > that hard to believe for a crystal, especially as the > frequency counter > indicates it's running at the correct speed. Loading the > crystal I would > assume would slow it down if anything, not speed it up another reality check: when loaded with the counter, does the speed still time at 1 second off? Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

In message <028301c4efe9$b7ef53b0$d201a8c0@y2k> Russell McMahon <RemoveMEapptechTakeThisOuTparadise.net.nz> wrote: > Quick reality check: > > Is it out by 2 seconds in 2 minutes, and 3 seconds in 3 minutes, or 1 > second in each case? After 74 minutes, it seems to be running between 10 and 11 seconds fast. The load caps are a pair of trimmer capacitors set to 33pF (checked with my Peak Atlas LCR meter). By my calculations, that's 0.142 seconds per minute. The rated load capacitance for the crystal (assuming the catalogue is correct - I don't have a datasheet for the xtal) is 15pF. Later. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, spamBeGonephilpemspamBeGonephilpem.me.uk | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.me.uk/ | 48xCD, ARCINv6c IDE, SCSI ... As long as I can remember, I've had amnesia.

Jinx wrote: > - see how much time it loses over a long period. This may > (or may not) reveal that it's counting something like 59.x > second minutes or 59m59s hours I think Jinx is on to something here. Your error is much too big to be explained by crystal cap value being wrong. Single step thru your rollover logic from 59 seconds to 1 minute. This smells like an off by one problem. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

> After 74 minutes, it seems to be running between 10 and 11 > seconds fast. The load caps are a pair of trimmer capacitors > set to 33pF (checked with my Peak Atlas LCR meter). By my > calculations, that's 0.142 seconds per minute. The rated load > capacitance for the crystal (assuming the catalogue is correct - I > don't have a datasheet for the xtal) is 15pF Here are some pdfs, all quite small, about the PIC oscillators and component selection. (Home > Design - App Notes > Design Practice - Oscillator) www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1490& filterID=414 There's also this section from the Mid-Range Reference Guide (110kB) http://ww1.microchip.com/downloads/en/DeviceDoc/31002a.pdf My suggestion is to get a clock with a ticking (not sweeping) second hand and have an LED flashing at 1Hz, as driven by your timer code. If the oscillator is good, the LED and clock shoud be in synch for a long time. If the oscillator is bad, they will drift apart, which will be very obvious. You won't need to do any measurement, it's just a good/ bad test When/if you find that there's nothing wrong with the 32kHz, it would be more fruitful to look at any error in terms of what's happening in the PIC, rather than a percentage or fraction. Then break it down into the possible causes for counting errors. There are a limited number of things that can go wrong, you need to eliminate them one by one. Trust me, it really pays to spend a little time looking hard at this. The problem with clocks is that to test them properly takes, well, it takes time, and waiting can be frustrating. You could try some accelerated testing, ie change any fundamental division/counting routines, and see if that magnifies the problem As discussed in a thread last year, the sound card on a PC, with either scope or audio capture s/w can be used as a long-term logic analyser. If you capture output from the PIC for an hour or so and look through it, you might find there's a double tick out or something like that. The PIC could actually be running fine but there's a regular s/w hiccup Have fun

> > After 74 minutes, it seems to be running between 10 and 11 > > seconds fast. I've just had a similar problem with a camera shutter timer I'm making and found that the problem was in the code rather than the osc source. Have you tried simulating this to see if you get the same behaviour? Mike. -- Outgoing mail certified virus free. Checked by AVG Anti-Virus. Version: 7.0.298 / Virus Database: 265.6.7 - Release Date: 30/12/2004

In message <000d01c4f049$a17f4d50$0500000a@ws1> "Mike Hawkshaw" <TakeThisOuTmikeEraseMEspam_OUTspikey-mike.com> wrote: > I've just had a similar problem with a camera shutter timer I'm making and > found that the problem was in the code rather than the osc source. Have you > tried simulating this to see if you get the same behaviour? I'm actually running it through an ICD2. I wonder if the ICD is introducing some interrupt latency somewhere - MPLAB seems to send a lot of "Ok, keep executing" type stuff to it (the BUSY LED blinks an awful lot). I'll bump the ICD2 into Program mode instead of ICD mode, reflash the chip with the no-debug code and see if that clears it up... Later. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, RemoveMEphilpemTakeThisOuTphilpem.me.uk | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.me.uk/ | 48xCD, ARCINv6c IDE, SCSI ... The Whispered Rule: People will believe anything if you whisper it.