At 07:00 PM 30/05/98 +0100, you wrote: >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 > > 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 -=====================================================================-