Timers On 18F PICs

[Geps]

Hi,

I have a subroutine that is used for decoding an asynchronous signal that uses Timer 1 to count between level changes as detected by the RB interrupt.

Timer 0 is used to time out the decoding to prevent hanging should there signal not be there.


Recently I've started to notice that once in every 100 or so occasions the Timer 0 overflow flag is getting set almost straight away. Needless to say the decoder then times out and it causes an error yet my logic analyser shows that the signal to decode is there.

Can someone please clarify the correct order for using Timers with interrupts on these chips? My approach so far has been to:
1) disable_interrupts(INT_TIMER0)
2) clear_interrupts(INT_TIMER0)
3) clear overflow flag
4) setup_timer_0()
5) set_timer0(0x00)
6) enable_interrupts(INT_TIMER0)

I personally feel this covers all the bases for why it would trigger pre emptively, but yet the problem persists.

I'm afraid it is part of work related project that I'm not readily able to post up here. PIC is a 18F4620 with 4.125 compiler.

[PCM programmer]

1. What interrupts are you using ? From your post, I think you are using
INT_RB and INT_TIMER0. Are there any more ?

2. What are the expected interrupt rates for INT_RB and INT_TIMER0 ?
You said that INT_RB interrupts on the edges of a signal that you are
decoding. What is the smallest interval between edges of the incoming
signal that can possibly occur ?

3. What is the oscillator frequency of your PIC ?


One way to help trouble-shoot this would be to use a logic analyzer.
If possible, devise a way to have it trigger when the INT_TIMER0
problem occurs, and then look carefully at the incoming INT_RB signal.
Look for any unexpected timing issues.

[asmboy]

Can you post the relevant code for:
the INT B handler,
the timer handler
the timer setup syntax ??
as well as master clock freq etc ??

[Mike Walne]

Yes, I realise you're in a commercially sensitve situation.

It really is simpler, to strip out all the bits you don't want us to see, then post the minimum possible, complete, compilable code which produces the problem.
Along, of course, with the details you've already been asked for.

Without more information, we're having to second guess.

I don't have a logic analyser, but have successfully used a digital 'scope in a similar situation.

Mike

[asmboy]

you do know that
1) disable_interrupts(INT_TIMER0)
2) clear_interrupts(INT_TIMER0)
3) clear overflow flag

AND
item
6) re-eneable .....

are done automatically FOR you when yo use the

#int compiler intrinsic in CCS -

look t the LST file to see


you DONT have to worry about thta bit in ccs !!!!

[Ttelmah]

Just a fractional correction here.

The _hardware_ performs 'disable_interrupts(GLOBAL)'. Not CCS.

The hardware also re-enables the interrupts _after_ you return from the handler (this is the RETFIE instruction - return from interrupt enable). The key point is that the re-enable _must_ happen after you leave the handler, to avoid any possibility of re-entrancy.

The 'overflow flag', _is_ the interrupt flag.

All CCS handlers _will_ attempt to clear the corresponding interrupt flag (unless you specify the handler with 'NOCLEAR'), but remember that in case of things like serial interrupts, this cannot be cleared unless the hardware condition has been cleared, which for these, your code must do.

Best Wishes