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.

 

Well, including your source code here will certainly help us to help u..

 

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.
}
}

 

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.

 

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.

 

Pommie or whoever sees this first:

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

Thanks

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

__________________
Mike
My website: www.ElectroBird.net

 

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.

 

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.

 

GreenBeret , which simulator software do you use?

__________________
Mike
My website: www.ElectroBird.net

 

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.

 

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.

 

You should try simulating the .hex file with Oshonsoft.

__________________
Mike
My website: www.ElectroBird.net

 

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?

 

The 16f72 isn't really a common chip? They maybe made a typo for just that chip...you should be able to edit it if you change the include files (pic16f72.inc).

__________________
Mike
My website: www.ElectroBird.net

 

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.

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.