Problem understanding why my interrupt isn't working

[eyewonder300]

I want to be able to enable/disable interrupt for Timer2 at different times in the program, to get a required delay (yes, I could use delay_us(), but I am having timing problems with that).

When Timer two overflows & interrupts, I want it to set a flag for me to wait on. What is supposed to happen is that I clear the flag I use to monitor the interrupt, enable the interrupt, start waiting, it overflows in 3.3mSec, enters the isr, and then sets the flag, and I do the other things I need.

My 'Set_Strobe' & 'Clr_Strobe' are lines that I can monitor with my scope.
What does appear to be happening is that as soon as I enable the interrupt, the isr fires, asserts my flag & does a 'Set_Strobe' without doing the 3.3mSec delay that I expected. The 'Set_Strobe ' signal gets asserted for only 15uSec, looking at my scope. And the other 'output_bit' pins are showing a time between interrupts of 20mSec, not the expected delay_ms(20) PLUS the 3.3mSec expected for the Timer2 overflow isr.

The chip is PIC16F876a, and compiler is 4.069.

Help is appreciated.

Cheers,
Steve

[asmallri]

T2_Delay_Complete does not get initialized.

T2_Delay_Complete should be declared as volatile however I do not know if CCS requires this as it may internally treat variables as volatile by default.

Timer 2 is free running and you do not initialize timer 2 value before enabling the interrupt which means the delay is random.

You did not need to use interrupts. You could simply initialize the timer count and clear the timer interrupt flag then poll the timer interrupt flag until it is set.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[eyewonder300]

I guess I am confused - wouldn't volatile mean that the value was lost after exiting an isr (or subroutine)?

T2_Delay_Complete initialization - it was there in the full code which didn't work, but inadvertently stripped it out for the test. I'll put it back in this evening, and try it, along with declaring "Volatile T2_Delay_Complete as Boolean".

Thanks,
Steve

[Ttelmah]

Volatile has no effect at all in CCS. It is used in some compilers to say that a variable _may_ be altered by something else, such as an interrupt handler. In CCS, you need to provide protection for this yourself. If you use a variable longer than a byte, and access it both in an interrupt, and in external code, you need to disable interrupts in the external code, while the variable is accessed, or you could get 'half the value coming from before an interrupt, and the other half from after......

Best Wishes

[gpsmikey]

To expand a bit on what Ttelmah was saying - I got bitten with this one some years back using an older version of the CCS compiler with an 876a part. My ISR set a flag in memory. My "Main" sat in a tight loop looking at that variable and when it changed, it did something. Unfortunately, the compiler decided that since nothing in my main code modified that variable, it "helped" me by optimizing the variable into a register variable -- which never changed. The ISR changed the real one, but since the compiler had "helped" me by making it a register variable for the loop, it never saw it. Declaring the variable as "volatile" forced the compiler to re-read the variable from memory each time around the loop and hey, wonderful, now my code ran as expected !!! (every time the ISR went off, it would read some bits from the port and stuff them into the variable that Main() was supposed to be watching.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[John P]

One thing to beware of if you're using interrupts which are disabled and then enabled again, is that you must clear the interrupt flag before the enable operation (for TMR2 on a PIC16F877A, that's TMR2IF, PIR1.1). If you don't, and if the interrupt would have occurred earlier if you hadn't disabled it, then you'll see an immediate interrupt as soon as you do enable it.

This is mentioned in the manual but I have failed to take note of it quite a few times.

[eyewonder300]

Good ideas, which I will be trying this weekend.

But a (simple) question - how do I clear the interrupt flag? I don't remember seeing anything specific like that in the compiler manual.

Thanks for the good suggestions. I will update upon success.

Cheers,
Steve

[gpsmikey]

Another reason not to have any delays inside an ISR.

One thing I have done in the past that works well is to set an unused bit high at the start of the ISR then clear it at the end of the ISR - makes it very easy to see just how much of your total time is being spend in the ISR with a scope probe.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[Ttelmah]

[eyewonder300]

It seems to have been a sequencing issue. The code posted below works as expected. The commented out interrupt enable in Main at that position would immediately clear the 'Strobe' signal, resulting in the 1.5uSec Strobe signal I was seeing with the scope.

Enabling the interrupt, then setting strobe & clearing my flag made everything work as expected.

Thanks to all for the help.

Cheers,
Steve

[asmallri]

[Ken Johnson]

One thing I have done in the past that works well is to set an unused bit high at the start of the ISR then clear it at the end of the ISR - makes it very easy to see just how much of your total time is being spend in the ISR with a scope probe.

mikey


Caveat: this shows how much time is spent in **your** code in the isr, but not the isr "overhead" of saving/restoring registers, which can easily be much more when your code is short and sweet . . .

Ken

[gpsmikey]

Good point on the overhead - but if that pulse is at 80%, you probably should look at your ISR code

I was used to writing my own ISR in assembly language for things like the Z-80 where I did all the overhead as well. Anybody remember the old TI 9900 processor ? One of the fastest context switches in it's day - all registers except the acc and workspace pointer were in RAM - you simply changed the workspace pointer to a new area of RAM and hey, presto 16 new registers There were two versions of the chip - TMS9900 that was a MOS device and the SBP9900 that was injector logic (and rad hard) which made it interesting to anybody doing military stuff back in the 70's.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[Ttelmah]

Yes, in fact a lot of the older processors were 'better' for fast ISR responses.

The Z80 itself had a duplicate register set, and a couple of the Motorola chips also allowed multiple register sets to be held 'in RAM'. Downside of that is of course that it makes the speed relatively slower than using internal registers that can be accessed at the same time as performing other memory operations, but it does seem 'daft', when old processors running at a very few MHz, can easily outperform 'modern' chips internally running hundreds of times faster for ISR responses.....

Generally, 'embedded' chips, are more likely to find systems allowing really fast ISR responses, especially those aimed at the RTOS market. Texas still produce embedded chips for which this is true.

Unfortunately, the PIC is particularly 'bad' in this regard, and CCS's implementation makes it worse....
Campaign for a bit of smartness in their interrupt handler, with it only saving registers that _are_ used in the interrupt code!. It shouldn't be that hard to actually do, and would make a massive difference.

Best Wishes

[ckielstra]