My suggestion would be fine tune the crystal first using a program that excites the crystal and outputs its frequency (a replica of the signal) on a third pin, so you can measure the frequency without loading the crystal. Only then, you should compensate for the missing seconds in software.

You can also use a DS32KHZ TCXO from Maxim. Then, the 5ppm(ish) deviation of your tuning fork crystal is no longer a factor (because I suspect, from my experience, that the deviation was measured inside a room with constant temperature, no wind, and also during the right phase of the moon, and something in the order of 200ppm would be more realistic for that crystal).

Thanks for the suggestion. The crystal seems to be working fine, but a few other glitches that I have not ye mentioned makes me think that the device's internal oscillator is not quite robust. I've connected my scope for a few moments at the crystal's leads to see what happened. And sure enough, a beautiful and clean sinusoid with an amplitude of about 1.5V appears on the screen. Only for it to gradually lose amplitude and almost disappear due to the capacitive load that the scope's probes induce on the circuit. But hey, that proves that it's working fine and without distortions.

I've followed @Tesla23 's suggestion, and a few SiT1552 are right now on the way now so I can test them. Maybe things will change for the better after that.

 

That is completely normal and expected, especially when measuring the return signal from the crystal to the PIC. Also, when using the tuning fork xtal, you will have some deviations. Temperature will be a factor as well in that case.

As for the SiT1552, it is definitely better than that crystal. You just need to feed to one pin to the PIC, where it is expecting the input from the 32KHz crystal, and leave the other pin unconnected.

By the way, have you tried to use an interrupt that is triggered by the timer that the crystal feeds to? I don't know the intricacies of your program, hence my question.

 

That is completely normal and expected, especially when measuring the return signal from the crystal to the PIC. Also, with the tuning fork, you will have some deviations. Have you tried to use an interrupt that is triggered by the timer that the crystal feeds to?

Yes I have. I take it you haven't read the whole thread yet, but that's alright.

Here's my problem, in one sentence: I have been able to obtain perfect two-seconds interrupts using an external crystal connected to the device's OSC pins, but so far I've been unable to internally program and configure the necessary parameters for it to generate one-second interrupts.

 

Sorry, meanwhile I've updated my reply. It is strange that the accuracy is ok when doing two second increments, but not with one second increments. But it probably boils down to your code. As far as I can see, you are using the interrupt correctly.

I didn't read the whole thread, sorry.

 

Here's my problem, in one sentence: I have been able to obtain perfect two-seconds interrupts using an external crystal connected to the device's OSC pins, but so far I've been unable to internally program and configure the necessary parameters for it to generate one-second interrupts.

Even after fixing the comment line above? That was keeping the second interrupt from happening. If the LED is correctly indicating a 2 sec interrupt period after fixing that then there is something else going on.

I’ll look at the osc again. puzzled. Sorry for short posts. On iPhone

 

Even after fixing the comment line above? That was keeping the second interrupt from happening. If the LED is correctly indicating a 2 sec interrupt period after fixing that then there is something else going on.

I’ll look at the osc again. puzzled. Sorry for short posts. On iPhone

Yes, even after that. And btw, that bug never made it into the code, it was a typo that I fixed after I posted that message.

Take a look again at post #56 for clarity. I had to edit it because I made a (yet another) typo and mixed my message into the code section.

 

Ok. Thanks for the clarification. I’ll check it out

 

Ok. Thanks for the clarification. I’ll check it out. Sorry for missing that

 

I set breakpoints in the ISR and TMR1 counts 32768 (0x8000) between flashes, which should be 1 sec.


Actual TMR1 readings at that breakpoint are 1284h and 9284h.

 

Your 2-second pulse rate puzzles me. The following occurs within the interrupt:

;*****************************************************************************************
Flash_Led_Once:
       banksel LATC            ;Bank 2
       bsf LATC, LED_PIN       ;turn on the LED connected to RC5
       call Delay_0.005_sec    ;wait for 0.005 seconds
       bcf LATC, LED_PIN       ;turn the LED off before leaving

       movlw d'30'
       movwf TEMPVAR2          ;common RAM
Flash_Led_Once_Loop:
         call Delay_0.005_sec  ;wait for 0.15 seconds before leaving
        decfsz TEMPVAR2, f
       goto Flash_Led_Once_Loop

What happens if you return immediately after clearing LED_PIN (line6)? That is, why the subsequent wait while still in the interrupt? Is it possible you are missing a potential interrupt during that 150 milliseconds? (The changes I made to simulate (setting system clock to 32 kHz, may obscure what is happening with both TMR1 and system oscillators running.) Just thinking out loud.

 

Did anyone mention a real time clock yet?

It is very hard to get a crystal to work right for time keeping such as for a wall clock. There are various issues that creep into the works such as temperature and noise.

5ppm is about 1/2 second per day (about 158 seconds per year), but you'd be very lucky to see that in the real world. It is much better to get a RTC board and read the time when you need to have it logged. The best RTC boards use a chip that has temperature compensation built in. I would bet you will never be able to match that accuracy and stability with anything you can build yourself starting with a raw crystal even if you incorporate a time adjustment routine in code to try to make up for the inaccuracy and probably even with a temperature measurement using a good temperature sensor.

Microchip had a good app note on using crystals but i dont think that will help either.

 

Hm, has anyone thought of using a Neo-6M GPS module, which can give an accurate 1Hz pulse (PPS output). Only gotcha is you have to verfiy the device has a GPS lock, usually by reading the serial port with a UART. I'm sure one can read the module at 9600 without too much overhead, and all you have to check is the data stream that indicates "lock".
With that pulse, you can trigger an interrupt accurately every second.

 

So I ran this up on hardware using the -ME2 emulator (I don't have a chip). The TIMER 1 oscillator works fine as does the TIMER 1 overflow interrupt but at the low 31KHZ system clock speed, the capture function gets erratic. Thinking about it, I suspect there is some internal clocked synchronization with Tcyc that causes the timer count to be missed by the clocked capture hardware. I ran the system clock up and at >= 125KHz, it works reliably, interrupting on both TIMER1 overflow and CCP compare. This smacks of something with the Fosc/4 -> Tcyc internals 31KHz * 4 < 125KHz so a 125KHz Fosc would be fast enough to latch the compare. Just conjecture but fits the observations.

The simulations missed all of that and I didn't pick up on the low system clock speed.

EDIT:
Duh. From Table 30-7 of the datasheet:
CCP Input Period (min) = 3*Tcyc +40ns
So... I doesn't look like the CCP is a valid option.

Sorry to lead you astray.

 

So... I doesn't look like the CCP is a valid option.

But it would be if I were to run the system clock externally using a dedicated 32.768 KHz oscillator, right?
That would mean that the Timer1 and the system clock would be running at exactly the same speed, so the synching problem would disappear... correct?

EDIT: And no, Timer1 would not be running from a separate oscillator anymore, but rather from the system clock.

 

I don't see why that is a problem. In capture, isn't CCP comparing to TMR1H/L? That must take a little time, perhaps a whole TCY. (Edit: That was an aside and was not meant to change the Microchip requirement of a little more than 3 TCY). Assuming a system clock of just 8 MHz, that's a 500 ns TCY. 3TCY +40 =1540 ns = 649 kHz. Your 32 kHz TMRI clock should be no problem.

Edit: The following is wrong. I forgot to use the correct formula. See post #83.
Running the system clock at 32 kHz might be a problem, if you use Fosc for TMR1, not Fosc/4 for TMR1 clock. In other words, I read that restriction as saying that TMR1 clock cannot be faster than the system (instruction) clock, given that TCY = Fosc/4. The period for that is usually > 40 ns.

 

I read that restriction as saying that TMR1 clock cannot be faster than the system (instruction) clock,

Perhaps that is exactly what is happenning here... I'm running the system clock at 31 KHz and Timer1 at 32.768 KHz...

 

Worth a try upping the system clock. If no cure, I would like to see what happens if you edit out the off delay (post #70).

Could do with MPLab SIM, but actual hardware is hard to dispute.

 

I would like to see what happens if you edit out the off delay (post #70).

Forgot to answer that question before, sorry.... The delay is there because the routine is meant to produce flashes at regular intervals. That is, a five repetition loop would call the flashing routine from the main code, and the LED would turn on and then off and wait in that state before the flashing routine returns. That way one gets even timing between flashes. Of course, in the previous simplified code it doesn't make any sense since the LED is being flashed only once when an interrupt occurs.

I've already tested the Timer1 interrupt with much longer code, and it doesn't affect it as long as the interrupt vector is exited before Timer1 rolls over. I've even tested it with code that takes 1/2 a second to execute, and I've had no problems whatsoever.

 

Your 2-second pulse rate puzzles me. The following occurs within the interrupt:

;*****************************************************************************************
Flash_Led_Once:
       banksel LATC            ;Bank 2
       bsf LATC, LED_PIN       ;turn on the LED connected to RC5
       call Delay_0.005_sec    ;wait for 0.005 seconds
       bcf LATC, LED_PIN       ;turn the LED off before leaving

       movlw d'30'
       movwf TEMPVAR2          ;common RAM
Flash_Led_Once_Loop:
         call Delay_0.005_sec  ;wait for 0.15 seconds before leaving
        decfsz TEMPVAR2, f
       goto Flash_Led_Once_Loop

What happens if you return immediately after clearing LED_PIN (line6)? That is, why the subsequent wait while still in the interrupt? Is it possible you are missing a potential interrupt during that 150 milliseconds? (The changes I made to simulate (setting system clock to 32 kHz, may obscure what is happening with both TMR1 and system oscillators running.) Just thinking out loud.

It I recall correctly, the interrupt should act immediately (that is why it is called interrupt, because it interrupts the main routine). The delay should have no influence whatsoever, unless the MCU has a design problem, or the "Delay_0.005_sec" is using another interrupt that takes priority over the interrupt that your timer triggers. This is just a thought.

 

the interrupt should act immediately

Interrupts do act "immediately" but the reaction time can vary between one and up to three instruction cycles, depending on conditions specific to each MCU.