Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Problem with Timer1

Status
Not open for further replies.

GreenBeret

New Member
i am facing a issue with my code. I enabled the PIE1<0> bit to enable timer1 interrupt. I am getting the interrupts for only sometimes, after that its not giving interrupt. I have a simulator software, when i test in that, i can see the PIE1<0> bit is getting cleared after some time... How this bit gets cleared automatically.. ? Pls help..

I am using PIC16F72 and Hitech C compiler.
 

GreenBeret

New Member
Below given is the code...

//include file
#include <pic.h>

//16F72 configuration word according to the features required.
__CONFIG(0x3FB1);
//main function
void main(void)
{
TMR1H |= 0b11000000; // Making Timer1 a 14bit counter.
//T1CON = 0B001111; // Original
T1CON = 0B000001; // Test with 4.0 MHz crystal...
INTCON = 0B10000000;
TMR1IE = 1;
GIE = 1; // enable global interrupts
PEIE = 1; // peripheral interrupt enabled.

while ( 1 )
{

if ( timerTick )
{
timerTick = 0;
//do other processing...
}
}
}

/*
Interrupt routine.
*/
void interrupt
isr( void )
{
// Checking for whether timer1 interrupt.
if ( TMR1IF )
{
TMR1IF = 0; //Clearing the interrupt flag.
timerTick = 1; // Setting flag used by main function.
TMR1H |= 0b11000000; // Making Timer1 a 14bit counter.
}
}
 
Last edited:

Pommie

Well-Known Member
Most Helpful Member
If the "//do other processing... " takes longer than 16mS then there will be occasions when it misses the setting of timerTick.

Edit, BTW, instead of making it 14 bit why not set the prescaler to 4?

Mike.
 
Last edited:

GreenBeret

New Member
Thank you Pommie for your reply.
i am not sure //do other processing code are taking more than 16mS, but even if it is taking morethan 16mS, how the TMR1IE flag getting reset?... Using simulator software, i can see after some iteration of timer1 overflow, the interrupt enable bit (TMR1IE in this case) getting cleared automatically.. This is the reason it is not calling my interrupt routine after some iteration. How this will happen?

One more thing i noticed now is i am using PORTC(rc6,rc7) for taking two input. I am setting TRISC=0; If i comment those codes in the pgm, the timer works fine and i am not getting this problem. Is there any reason PORTC data may corrupt my interrupt flag?.

The reason for setting top two bits in Timer1 is to make a delay of 0.5 second. I am using 32.768KHz crystal. If i didnt make it 14 bit, it will give me a minimum of 2 second delay only. Accoding to my understanding ( i am new to PIC ) setting prescaler is to make the more delay than reducing the delay. Correct me if i am wrong.
 

birdman0_o

Active Member
Pommie or whoever sees this first:

In C do you need to do context saving during an interrupt?

Thanks :D

P.s. is it not feasible to try this program out in hardware?
 

Pommie

Well-Known Member
Most Helpful Member
TMR1IE should never change unless you change it. TMR1IF should get set whenever timer1 overflows and cause the interrupt. Do you have a compilable file that demonstrates the problem. Also, which compiler are you using?

You are correct about the prescaler. I wasn't thinking. The stupid thing is someone suggested the same thing in this thread and it was me that pointed out the error. How ironic I make the same mistake a week later. Lol.

Edit, there is one way the flag can get cleared and that is a rogue memory pointer. Something like a clear buffer routine.

Mike.
 
Last edited:

Pommie

Well-Known Member
Most Helpful Member
Pommie or whoever sees this first:

In C do you need to do context saving during an interrupt?

Thanks :D

P.s. is it not feasible to try this program out in hardware?

It depends on the compiler but most save context for you. Some even clear the interrupt flags for you which is really silly, I believe the CCS compiler does this.

Mike.
 

kpatz

New Member
Could it be a bank issue? On some PICs the TMR1IE is in one bank while TMR1IF is in the same address in a different bank. If you enter the ISR and clear TMR1F without setting the bank bits correctly, you could be clearing TMR1E. But if you're programming in C the compiler should be handling the bank bits for you.

Can your simulator cause a breakpoint when TMR1IE changes? Then you can see exactly where it's changing.

If you have the WDT enabled you could be having a WDT timeout that you aren't expecting too.
 

GreenBeret

New Member
Yes I have the full C code. I am using Hitech C freeware compiler. I can send u the file if you can have a look. Thanks in advance.
 

GreenBeret

New Member
Finally I found out the cause of this using Simulator.
Excellent kpatz. Your assumption was absolutely correct. This is a Bank problem. In this PIC (16F72), the TMR1IE is in one bank while TMR1IF is in the same address in a different bank.
But I am using C compiler (HI-TECH C coming alone with MPLAB free version, i think its a free version know as Lite). Why my compiler is not handling this issue? If is it so, how can i trust this compiler?

Can anybody suggest a good C compiler (freeware) for prgming PIC ICs?
 

Pommie

Well-Known Member
Most Helpful Member
Just tried this in HiTech C and it is indeed a banking error. The include file is correct and so it is the compiler getting it wrong.:eek:

You could switch to BoostC but the syntax is rather different. They do have a converter built into their IDE. See here for details.

Mike.
 
Status
Not open for further replies.

EE World Online Articles

Loading
Top