Searching \ for 'Interrupt triggered when intcon mask clear - help!' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ints.htm?key=interrupt
Search entire site for: 'Interrupt triggered when intcon mask clear - help!'.

Truncated match.
PICList Thread
'Interrupt triggered when intcon mask clear - help!'
1998\05\30@140347 by Andy Shaw

flavicon
face
Hi I've been struggling with a problem for a while now so I thought that
maybe somebody out there may have seen this one before.

Basically I'm seeing my RBIE/RBIF (Int on port b change) interrupt routine
being called even though the RBIE (enable flag) is clear. Basically my int
handler looks like this.....

InterruptVector
    push                 ; Always save registers etc
CheckInterrupt
    btfsc INTCON, RBIF   ; Is it a PORTB int ?
    goto ServicePORTB    ; yes so go do it
...
...
ServicePORTB
    btfss INTCON, RBIE   ; Test to see if we have ints enabled
    nop                  ; This should never be executed!
    bcf INTCON, RBIE     ; turn off further ints
    movf PORTB, W        ; read port to reset it
    bcf INTCON, RBIF     ; say we have seen this change
....
....

EndInterrupt
    pop                  ; restore things
    retfie               ; return and re-enable ints

Ok what I see happening is that if I set a breakpoint on the nop just after
the ServicePORTB label. Then From time to time I get a break. This was
really screwing up the rest of my interrupt routine (easy to fix just
replace the nop with a goto to skip the int routine). What seems to happen
is that the int routine gets called once with RBIE enabled - OK, then
immediately again with RBIE now disabled - not so good. So my question is -
should this happen? If so why? BTW the interrupt gets enabled (RBIE set in
the main body of the code

The environment I'm using is an ICEPIC emulator with the
16C71/16C7110/16C711 module installed. The signal that I'm feeding into a
single pin on PORTB is a rather noisy standard Radio Control pulse (+ve
pulse of length 1-2mS repeated every 20mS).

Thanks

Andy

1998\05\31@194414 by Dennis Plunkett

flavicon
face
At 07:00 PM 30/05/98 +0100, you wrote:
{Quote hidden}

Hello, bit of trouble eh?
Ok, the code looks simple enough and from what I can see you shouldn't get
into the interrupt routine when RBIE is clear. You indicate that this
happens from time to time, thus during the normal run period? So when the
break occurs the RBIE flag is clear, this would indicate that the interrupt
is disabled:-

1.      Does any part of your code set this flag other than the main section?
2.      Did an interrupt occur that caused this condition?

Those are the simple parts, the next thing is the code itself, can you look
at the code trace?
Do you do any modifications to the Programme counter, you know things like a
look up table where you change the contents of the programme counter. The
reason for this is simple, often code will vector into an unrequired code
section if either:-

1.      Uncontrolled setting of the programme counter (Check mods on PACL?)
2.      Stack overflow (Check call level)

Both of these points can be found by code inspection.

Hope I have helped

Dennis
-=====================================================================-

Dennis Plunkett: Embedded Hardware, Software design
NEC Australia DRMASS
Line Interface cards
TRX software
ISDN interface card
ph 03 9264-3867

-=====================================================================-


'Interrupt triggered when intcon mask clear - help!'
1998\06\02@062554 by Caisson
flavicon
face
> Van: Andy Shaw <spam_OUTandy.shawTakeThisOuTspamVIRGIN.NET>
> Aan: .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
> Onderwerp: Interrupt triggered when intcon mask clear - help!
> Datum: zaterdag 30 mei 1998 20:00
>
> Hi I've been struggling with a problem for a while now so I thought that
> maybe somebody out there may have seen this one before.
>
> Basically I'm seeing my RBIE/RBIF (Int on port b change) interrupt
routine
> being called even though the RBIE (enable flag) is clear. Basically my
int
> handler looks like this.....

[Cut]

Andy,  the RBIF-flag is set regardless of the RBIE-flag.  To see if a INT
took place _and_ was enabled, you will have to AND them together (or to
check for the RBIE-flag in the service-routine.

Greetz,
 Rudy Wieser

P.s.
I had the same problem when using the USART and TIMER0 together

1998\06\02@072642 by Dr. Imre Bartfai

flavicon
face
On Mon, 1 Jun 1998, Dennis Plunkett wrote:

{Quote hidden}

Another bogus location:

have you branch around ServicePORTB ? Otherwise you can enter it unwanted
fashion... (xcus for a simple option, but it is still possible).

Imre

1998\06\02@184610 by Andy Shaw

flavicon
face
Hi Caisson,
Yeah I've had this problem as well (sigh). I should have said in my original
posting that the *ONLY* interrupt that I ever enable (in the intcon reg) is
RBIE. When I get a break on the noop all of the intcon enable flags are
clear except GIE.

Thanks

Andy

-----Original Message-----
From: Caisson <caissonspamKILLspamTELEBYTE.NL>


{Quote hidden}

1998\06\03@062917 by Caisson

flavicon
face
> Van: Andy Shaw <.....andy.shawKILLspamspam.....VIRGIN.NET>
> Aan: EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU
> Onderwerp: Re: Interrupt triggered when intcon mask clear - help!
> Datum: dinsdag 2 juni 1998 23:43
>
> Hi Caisson,
> Yeah I've had this problem as well (sigh). I should have said in my
original
> posting that the *ONLY* interrupt that I ever enable (in the intcon reg)
is
> RBIE. When I get a break on the noop all of the intcon enable flags are
> clear except GIE.
>
> Thanks
>
> Andy

Another thing comes to mind : The interrupt latency.  When you disable a
Interrupt the interrupt-handler (especially the RETFIE instruction) could
re-enable it.  There is a piece of code in my book that states that you
have to _check_ if your interrupt is off.  Example states :

LOOP:
 bcf INTCON,GIE
 btfsc INTCON,GIE
 goto LOOP

Hope this is the solution to your problem ...

Greetz,
 Rudy Wieser

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...