RTCC code in Microchip App note erroneous?

[PICMICRO]

I think **broken link removed** by Microchip has a flaw. It uses 32768 Hz oscillator for Timer1 and Writes values to timer1 so that supposedly 1 interrupt occurs every second.
The part of interest is in this code.

void interrupt intsrv(void)
{
		if (TMR1IF)
		{
			TMR1H = 0x80;
			TMR1L = 0;
			TMR1IF = 0;
			
			// service the clock
	
			rtcc.time.seconds++; 
                         ... //rest of the codes

Won't this code increment the seconds at a rate slightly more than 1Hz because of interrupt latency and all ?
But since this code came directly from Microchip, I just wanted to confirm.

 

[Sceadwian]

I don't see anything wrong here. Care has to be taken when writing code that depends on Interupts especially from multiple sources, but nothing like that going on here. Basically you just have to make sure that the interupt routine is serviced before the next event otherwise you'll miss it, it's mostly a problem with noisy external interrupts.

 

[PICMICRO]

when TIMER1 is written with 0x8000 it will require 32768 cycles (= 1 second) to do the roll-over(and to generate Interrupt).
But, we won't reach the "rtcc.time.seconds++;" code instantly when the interrupt occurs. (interrupt latency)
So, I guess more than 1 second will have elapsed between each consecutive execution of "rtcc.time.seconds++;" code.
Thanks for your reply, and I hope to learn more.

 

[Mike - K8LH]

I don't see anything wrong here.

Really? If the low byte of the free running counter is reset to zero, wouldn't you lose counts?

 

[PICMICRO]

Really? If the low byte of the free running counter is reset to zero, wouldn't you lose counts?

That was exactly what I was trying to tell. You put it straight. Thanks.

 

[Sceadwian]

Ahh I see now, yeah it would be slightly off. How long does it take to get to the timer clear? I know nothing about PIC latency. I'd hazzard a guess it's around 4-8 system clocks? If it's 8 system clocks till the exact moment the final clear occurs and the system clock is 8mhz then the second will actually be 8usec longer. Over the course of a year it would be off by a little over 4 minutes, not exactly critical. Anything requiring higher accuracy then that would need something more sophisticated than a simple quartz crystal anyways.

If someone can figure the exact latency till the timer byte actually gets cleared; this could be fixed by occasionally changing the timer value slightly lower to account for the accumulating micro seconds. The time constant of 32khz crystal is 30.5u seconds so once you determine the true latency (probably best done in a simulator) you can figure out how many seconds till the timer value has to be tweaked by one for the next second. Of course the latency of that extra code would have to be added as well but that's easily done.

Suffice to say, it's not really a flaw as the crystal accuracy itself could possibly be worse than the error the code introduces. The error increases as the actual system clock goes down, so you'd definitely want to correct for the deviation if the system clock was very low. There however should be a note about it in the Appnote, if the system clock is 32khz as well and the delay is 8 cycles that becomes a 2 hour per year difference that's a bit more significant.

 

[Mike - K8LH]

PICMICRO,

I can't help thinking that Microchip code is in error.

Have you tried just setting bit 15 of the TMR1 register and see what happens? It seems to work in simulation (for a 16F1828 project I have open)...

    		if (TMR1IF)
		{
                  TMR1H |= 0x80;

 

[PICMICRO]

Thanks Mike. I see that your code should work, because, you didn't disturb the Lower 15 bits.
How could Microchip Engineer's overlook such a simple solution, especially in a APP note for RTCC?

However, I am doing it by sing TIMER0, and I never write to the TIMER.
I am running the PIC in 32768Hz xtal frequency and No prescaler is used for TIMER0

	if(T0IF){
	        static unsigned char sec32 = 0; //every 32 ticks = 1 second
	        sec32++;
	        if(sec32==32){
	                 sec32 = 0;
			 seconds++;
               //.. rest of the codes

This works too.

@Sceadwian
In my simulation, I get latency of 12 instruction cycle. And since I am running my system at 32768Hz, if I follow Microchips code, my RTCC will be significantly inaccurate.
And, in the view that such simple solutions exist to overcome software flaw, there should be no doubt that it was an error rather than deliberate compromise as you said. (that xtal is going to be inaccurate anyway, so why bother with software?)
Thanks anyways.

 

[Sceadwian]

haha
Well I made the first mistake, but apparently no one read the full appnote =)

Timer1 can operate during Sleep mode to help reduce
the current consumption of the application. A Timer1
roll-over event (TMR1IF bit) will wake the
microcontroller from Sleep and execute the next
instructions. It should be noted that, upon an overflow,
the TMR1IF flag is set, but the counter continues to run.
Time and date update can be done at a later time,
provided that another Timer1 roll-over does not occur.[/]B

The section in bold directly suggests the same thing I did in my last post.

The reason there's no code to correct for it is because there is absolutely no hardware detail in the appnote just rough requirements, it's a general guideline for construction of an RTC not a detailed project description for an end user to simply assemble.

 

[ghostman11]

hi can i ask wich app note? i have been looking at a pic 24f last couple of weeks as i have a simple job for it. it has a onboard RTCC, i noticed in the datasheet they have a register for adding or decrementing cycles to adjust the accuracy are you sure there isnt something like this further on in the code?
i forgot to add the chip in question is PIC24FJ64GA104. BTW it wou;dnt be the first app note with errors there is a well known one with i think I2C slave mode code that completely wrong, or at least i think its I2C slave my memory is dim on it now as it was a while ago

 

[Mike - K8LH]

I think I found an error in an application note once; keypad scanning problem an557 16f628a

 

[3v0]

Remember when dealing with 16 bit timers on 8 bit PICs that the high byte we see is a shadow register which is set from the real high byte whey the low byte is read and shadow to high byte is written when the low byte is written.

That should make it impossible to set the high byte or any bit in it without effecting the low byte ?

 

[Mike - K8LH]

Remember when dealing with 16 bit timers on 8 bit PICs that the high byte we see is a shadow register which is set from the real high byte whey the low byte is read and shadow to high byte is written when the low byte is written.

That should make it impossible to set the high byte or any bit in it without effecting the low byte ?

That section of the (16F88) manual I'm looking at is a bit unclear about write operations.

Based on some old posts it seems you can write the TMR1H register without having to write TMR1L. And it also seems to be common practice to set TMR1H bit 7, immediately after an interrupt to insure that TMR1L doesn't roll-over, for one second interrupts, or set TMR1H bits 6 and 7 for half second interrupts.

 

[Sceadwian]

Ghostman this appnote was written for a 16F, the 24F you're talking about has a hardware RTC module? Unrelated.

 

[ghostman11]

erm the parts are unrelated but what i was trying to see was if there is a error in the app note or if something was being missed as it seems there are a few 'errors' but all seem to be timer related, having said that 3v0 makes a good point with the shadow register. so i guess what i am saying is what is being seen as wrong behaviour/error might not be

 

[ghostman11]

@picmicro if your looking for RTCC code have a look at roman blacks site, somewhere on there he has a one second algorythm thats meant to be pretty accurate, it has some kind of error corection in it.

 

[Pommie]

I agree that code is erroneous. Interestingly, the asm code in the 16F88 for a RTC is correct and uses bsf TMR1H,7.

As for it being impossible to write single bits of timer1. This is only on 18 and newer 16 series chips and can be turned on/off in software (T1CON,7).

Mike.

 

[Mike - K8LH]

I agree that code is erroneous. Interestingly, the asm code in the 16F88 for a RTC is correct and uses bsf TMR1H,7.

As for it being impossible to write single bits of timer1. This is only on 18 and newer 16 series chips and can be turned on/off in software (T1CON,7).

Mike.

Thanks for the clarification Mike (Pommie). That's good to know since I'm just getting ready to try a 32768 Hz crystal in a project for the first time.

Cheerful regards, Mike

 

[3v0]

Based on some old posts it seems you can write the TMR1H register without having to write TMR1L.

Last I checked the datasheets the only way to write the true TRM1H was by setting the value in TRM1H and writing to TMR1L.

As for it being impossible to write single bits of timer1. This is only on 18 and newer 16 series chips and can be turned on/off in software (T1CON,7).

My wife can tell you just how often I am wrong and for this reason alone I try to avoid putting to much stock in most anything I think.