Searching \ for '[PIC] INTCON/OPTION REG Weird Symptom' 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=intcon
Search entire site for: 'INTCON/OPTION REG Weird Symptom'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] INTCON/OPTION REG Weird Symptom'
2005\10\29@165900 by Debbie

flavicon
face
PICers - here's something that really had me stumped for a couple of days.
I wrote code to operate a camera. It configs the OPTION_REG and the INTCON as
shown, then waraps up housekeeping functions and goes to sleep to wait for an
interrupt on RB0 or RB6/RB7 keychange as case may be.

What nearly drove me nuts was the hardware kept self interrupting all the time,
yet the simulator (MPLAB) behaved normally.  ie It went to sleep, stayed
asleep. The protoboard hardware version (4MHz) would get to the sleep instruc
then jump to the ISR. Even if I left GIE cleared.
I "cured" (?) it by changing the OPTION_REG from b'10000111' to b'00001000'

What I can't figure out is why? When you disable the INTCON (GIE=0), then it
shouldn't make any difference what you have in OPTION_REG?

Any ideas what's going on? ie are there any restrictions on what you can out
into the option register v/v interrupts?

Debbie

setint:
       BANK_1
       movlw    b'00001000'     ;Original config = '10000111'
                                ;b7 - RBPU' = 1 => Pull-ups disabled,
                                ;b6 - INTEDG = 1 => RB0 int. on rising
                                ;b5 - TOCS = TMR0 Clock Slct.
                                ;b4 - TOSE => Clock edge select
                                ;b3 - PSA = 1 =>  Prescaler assigned to WDT,
                                ;           0 => Prescaler assigned to TMR0
                                ;b2, b1, b0 : Prescaler Rate Select          
       movwf    OPTION_REG
       BANK_0
       PAGE_0
       movlw    b'00011000'     ;Disable interrupts for now. GIE=0
                                ;b7 - GIE=0 temporarily
                                ;b6 - Disable EE write
                                ;b5 - Disable TMR0 interrupt
                                ;b4 - Enable RB0 interrupt
                                ;b3 - Ensable Interrupt on change RB4-7
                                ;b2 - Clear TMR0 flag = no overflow
                                ;b1 - Clear RB0 int. flag
                                ;b0 - Clear RB port Change Int. flag    
       movwf    INTCON        

<..snip..>

call    power_off
       bcf     STATUS_LED
       clrf    flags
       movlw   b'10011000'     ;Now enable the interrupts
       movwf   INTCON
       nop
       sleep                   ;Shut down and wait for an interrupt
       nop
<..snip..>


               
____________________________________________________
Do you Yahoo!?
Yahoo! News: Get the latest news via video today!
http://au.news.yahoo.com/video/

2005\10\29@191558 by michael brown

picon face
From: "Debbie"


> PICers - here's something that really had me stumped for a couple of
days.
> I wrote code to operate a camera. It configs the OPTION_REG and the
INTCON as
> shown, then waraps up housekeeping functions and goes to sleep to wait
for an
> interrupt on RB0 or RB6/RB7 keychange as case may be.
>
> What nearly drove me nuts was the hardware kept self interrupting all
the time,
> yet the simulator (MPLAB) behaved normally.  ie It went to sleep,
stayed
> asleep. The protoboard hardware version (4MHz) would get to the sleep
instruc
> then jump to the ISR. Even if I left GIE cleared.

This is pretty much impossible.  If GIE is clear, ints aren't going to
fire.

> I "cured" (?) it by changing the OPTION_REG from b'10000111' to
b'00001000'
>
> What I can't figure out is why? When you disable the INTCON (GIE=0),
then it
> shouldn't make any difference what you have in OPTION_REG?

The OPTION reg shouldn't have any effect whatsoever on your port change
interrupts.  Chances are much more likely that you have left the
watchdog running accidentally or have interrupts occurring while you are
switched to bank1, but the ISR doesn't know it and it blindly smacks up
the wrong registers.  Or the ISR switches back to bank0, but doesn't
properly save/restore the context info causing the main level code
suffer psychotic episodes.  Stuff like this won't always show up in
simulations.

> Any ideas what's going on? ie are there any restrictions on what you
can out
> into the option register v/v interrupts?

When you use port change ints, you have to read the port as well as
clearing the RBIF flag.  Otherwise the interrupt will trigger again
because a mismatch condition still exists against the magical hidden
shadow reg that holds the original pin values.  You have to read the
port before clearing the RBIF, or it will instantly change back to a 1
causing the int to fire again as soon as you execute the RETFIE.  This
reloads the magical hidden shadow reg.  ;-)  The simulator may not get
this right, it wouldn't be the first thing it didn't "simulate".

<snip code listing>

2005\10\30@145059 by Debbie

flavicon
face
--- michael brown <spam_OUTspam-meTakeThisOuTspamhouston.rr.com> wrote:
>
> The OPTION reg shouldn't have any effect whatsoever on your port change
> interrupts.  Chances are much more likely that you have left the
> watchdog running accidentally or have interrupts occurring while you are
> switched to bank1, but the ISR doesn't know it and it blindly smacks up
> the wrong registers.  Or the ISR switches back to bank0, but doesn't
> properly save/restore the context info causing the main level code
> suffer psychotic episodes.  Stuff like this won't always show up in
> simulations.
>
> When you use port change ints, you have to read the port as well as
> clearing the RBIF flag.  Otherwise the interrupt will trigger again
> because a mismatch condition still exists against the magical hidden
> shadow reg that holds the original pin values.  You have to read the
> port before clearing the RBIF, or it will instantly change back to a 1
> causing the int to fire again as soon as you execute the RETFIE.  This
> reloads the magical hidden shadow reg.  ;-)  The simulator may not get
> this right, it wouldn't be the first thing it didn't "simulate".
>

Thankz Michael! I tried swapping bsf/bcf INTCON,GIE for movwf INTCON & reading
PORTB. No diff. The only thing I've found so far that does make a diff - ie
causes the PIC (16F84) to stay asleep until interrrupted - is b7 (RBU') in the
OPTION_REG.

Hmm. OK, Pull up resistors - what //exactly// do they do or what are the
pros/cons of having them enabled/disabled? And how could it possibly affect the
interrupts?

And I thought I had a handle on all this  ... :(

Here's the cut-down code if interested. The context-saving is handled by MACROS
- they're basically the routines Mike Predko gave in his book.

Debbie


 PAGE
        org       0x00
start    goto      main

        org       0x04  
intrpt:  
        goto      alert
        goto      main         ;Catches any errors. We hope!

<Subroutines in here.>

main:    
     <Config the Ports>
 
setint:
       BANK_1
       movlw    b'00011111'     ; Works if RBU' is cleared.
                                ;b7 - RBPU' = 1 => Pull-ups disabled, 0 =>
enabled
                               
       movwf    OPTION_REG
       BANK_0
       PAGE_0
       movlw    b'00011000'     ;Disable interrupts for now. GIE=0
       movwf    INTCON        

       <Switch on LEDs & Stuff>
loop:
       call    power_off
       <Do stuff>
                               ;Michael Brown's trick  ---> read the port 1st
       movlw   b'11111000'
       andwf   INTCON,f        ;Clear the flag bits in INTCON
       movf    PORTB,w         ;Read PORTB and then
       bsf     INTCON,GIE      ;Enable the interrupt
                           ;My orginal code
                           ;movlw   b'10011000'     ;Now enable the interrupts
                           ;movwf   INTCON
       nop
       sleep                   ;Shut down and wait
       nop
       bcf     INTCON,GIE      ;Disable interrupts while doing housekeeping.
       goto    loop  


;The interrupt section ...

       include  "handler.asm"
alert:  
       call     intrpt_service
       bcf      INTCON,GIE            ;Disable interrupt temporarily
       goto     loop                  
       goto     main                  ;Catches errors .. we hope!
       end



       

       
               
____________________________________________________
Do you Yahoo!?
Yahoo! Photos: Now with unlimited storage
http://au.photos.yahoo.com

2005\10\30@150655 by Jan-Erik Soderholm

face picon face
What's in "handler.asm" ?
Doesn't matter realy, since it will
never run anyway.

Where is the RETFIE ?

And why does your ISR "goto loop" ?
Isn't "loop" outside of the ISR ??

>  bcf      INTCON,GIE     ;Disable interrupt temporarily
>  goto     loop                  
>  goto     main              ;Catches errors .. we hope!

Exactly *what* errors ?

Jan-Erik.



2005\10\30@180017 by Jinx
face picon face
>         include  "handler.asm"
> alert:  
>         call     intrpt_service
>         bcf      INTCON,GIE            ;Disable interrupt temporarily
>         goto     loop                  
>         goto     main                  ;Catches errors .. we hope!
>         end

Presumably "handler.asm" is the context saving. Does it apply
at BOTH ends of the ISR ? What is the routine "intrpt_service" ?

The ISR should be something like

   <context>
   bcf   intcon,rbif
   do what you have to with the IOC value
   <context>
   retfie

Entering the ISR automatically clears GIE, RETFIE re-enables it

It seems to me the problem isn't OPTION, it's probably the ISR.
At the very least the ISR needs to be re-written so it works properly,
otherwise you've got 2 unknowns. As it is at the moment, you are
probably experiencing stack overflow because the ISR is terminated
with a goto

Also

        org       0x04  
intrpt:  
        goto      alert
        goto      main         ;**** goto main is superfluous ****

2005\10\30@181646 by Jinx

face picon face
Debbie, once you've sorted out the ISR, you might want to
have a look at these three small pdfs

Using the Port B Interrupt on Change as an External Interrupt

http://ww1.microchip.com/downloads/en/AppNotes/00566b.pdf

Implementing Wake Up on Keystroke

http://ww1.microchip.com/downloads/en/AppNotes/00552e.pdf

http://ww1.microchip.com/downloads/en/AppNotes/00528d.pdf

There are some potential problems with IOC depending on the
actual application (eg if there's activity on PortB not related to
IOC). What I had to do in one case was to not use IOC and
simply diode-OR b4, b5 to b0 and use INTF instead. When
INTF is set, you look at b0, b4, and b5 to see which one(s)
went high to find the source of the interrupt ie

1 0 0 -> b0
1 1 0 -> b4
1 0 1 -> b5


2005\10\31@052810 by Jan-Erik Soderholm

face picon face
Jinx wrote :

> >         include  "handler.asm"
> > alert:  
> >         call     intrpt_service
> >         bcf      INTCON,GIE    ;Disable interrupt temporarily
> >         goto     loop                  
> >         goto     main                  ;Catches errors .. we hope!
> >         end
>
> Presumably "handler.asm" is the context saving. Does it apply
> at BOTH ends of the ISR ?

But since it is included *before* the label that the int
vectors jumps to, does it matter ?

Jan-Erik.



2005\10\31@055257 by Jinx

face picon face
> > Presumably "handler.asm" is the context saving. Does it
> > apply at BOTH ends of the ISR ?
>
> But since it is included *before* the label that the int
> vectors jumps to, does it matter ?

In the sense that it's included the wrong place then no

However, as the ISR in general needs a good tidy up, I was
just enquiring as to whether handler.asm is going to do the
context at both ends of the ISR. Without knowing exactly
what handler.asm is, it would appear that it possibly does
the job only on entry. If so, that's another thing that Debbie
needs to look at

2005\10\31@140455 by Debbie

flavicon
face

--- Jinx <.....joecolquittKILLspamspam@spam@clear.net.nz> wrote:

> > > Presumably "handler.asm" is the context saving. Does it
> > > apply at BOTH ends of the ISR ?
> >
> > But since it is included *before* the label that the int
> > vectors jumps to, does it matter ?
>
> In the sense that it's included the wrong place then no
>
> However, as the ISR in general needs a good tidy up, I was
> just enquiring as to whether handler.asm is going to do the
> context at both ends of the ISR. Without knowing exactly
> what handler.asm is, it would appear that it possibly does
> the job only on entry. If so, that's another thing that Debbie
> needs to look at
>

Hi Guys - I think I //know// what the problem was ... and I'm a dumbo. :(

I keep the pin assignments for PORTA & PORTB in a separate equates.inc file
PORTB was //supposed// to be configured like so -->
CONFIG_B EQU b'11000001'

OK, so somehow or other I had CONFIG_B = b'1100001'. Whoops, only 7 bits.
Apparently that causes b7 in TRISB to default to zero. So, when you enable
the pullups in OPTION_REG and set RBIE in INTCON so it's looking for an
interrupt-on-change @ the instant after RETFIE, what happens? :|

I guess in future it might be a better idea to keep the port configs in-line
with the main code, so they're easily visible.

Cut-down code shown below. The context save/restore is done with macros @ both
ends of the ISR. I included handler.asm at the end of the programmme because
it's getting quite unwieldy, and had the interrupt jump to a lable immediately
after the include.

Gentlemen, my thanks for your trouble!

Debbie :)


__CONFIG _CP_OFF & _WDT_OFF & _XT_OSC & _PWRTE_ON
<.. Equates & MACRO included files go here ..>

PAGE
        org       0x00
start    goto      main

        org       0x04  
intrpt:  
        goto      alert    

<.. Call the ISR handler  as a subroutine from the end of the programme ..>

<... "Included" subroutines & more MACRO files go here ...>
include "can_dly.asm"      ;Delays for the IR wave train
include "ir_codes.inc"    

setint:
       BANK_1
       movlw    b'10011111'     ;
       movwf    OPTION_REG
       BANK_0
       PAGE_0
       movlw    b'00011000'     ;Disable interrupts for now. GIE=0
       movwf    INTCON        

loop:
       call    power_off
       bcf     STATUS_LED
       IR_LED_OFF              ;Make sure the IR LED is OFF (Active LOW)
       clrf    flags
       call    picwait         ;Pause so we can seee what's happening?? :(

       movf    PORTB,w         ;Read PORTB and then
       bsf     INTCON,GIE      ;Enable the interrupts
       nop
       sleep                   ;Shut down and wait for a bandit
       nop
       goto    start           ;Not needed but it's here "in case"


<..In-line subroutines go here. Quite a lot of'em ...>
<... Last of all, the ISR handler is included here ...>
       include  "handler.asm"
alert:  
       call     intrpt_service
       bcf      INTCON,GIE            ;Disable interrupt temporarily
       goto     loop                  ;Do housekeeping after ISR
       nop
       goto     start                 ;Not needed but it's here "in case"
       end


;*******************************************************
;The ISR (cut down)  ... "handler.asm"

intrpt_service
        PUSHSTATUS               ;Save current configuration
int_break01:                      ;Breakpoint for de-bugging
        bsf       STATUS_LED     ;Turn ON the STATUS LED. Shows interrupt
handler is working. Active HIGH.
    <... ISR code in here ...>
        bcf       STATUS_LED     ;LED OFF. Shows we're leaving the handler.
int_break02:                      ;End of ISR de-bug breakpoint
       POPSTATUS
       retfie


;*****************************************
;The context saving MACROs
PUSHSTATUS  MACRO
           movwf     w_            
           movf      STATUS,0
           bcf       STATUS,0      ;Put registers into known page
           movwf     STATUS_
           movf      PCLATH,0      ;Save PCLATH
           movwf     PCLATH_
           movf      FSR,0
           movwf     FSR_
           ENDM

POPSTATUS MACRO
         movlw     b'00011000'   ;Reset the INTCON bits BUT ...
         movwf     INTCON        ;.. let the PIC set GIE upon retfie
         movf      FSR,0
         movwf     FSR
         movf      PCLATH_
         movwf     PCLATH
         movf      STATUS_,0     ;Return from interrupt
         swapf     w_            ;Flip & load the w register
         swapf     w_,w          ;without affecting the STATUS reg.
         ENDM




               
____________________________________________________
Do you Yahoo!?
Listen to over 20 online radio stations and watch the latest music videos on Yahoo! Music.
http://au.launch.yahoo.com

2005\10\31@144100 by olin piclist

face picon face
Debbie wrote:
> I guess in future it might be a better idea to keep the port configs
> in-line with the main code, so they're easily visible.

Even better would be to use something like my preprocessor.  This has /INBIT
and /OUTBIT commands for defining each of the port pins.  The standard PORT
module then initializes all the ports, including the passive pullups,
according to the assembly time state left by /INBIT and /OUTBIT.  For
details see the PREPIC documentation file at http://www.embedinc.com/pic.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\10\31@144819 by Jan-Erik Soderholm

face picon face
Debbie wrote :

> Hi Guys - I think I //know// what the problem was ... and I'm
> a dumbo. :(
>
> [snipped the part about port pins...]

And what about all other problems people have
pointed out ? You just decide to ignore them, or ?

Your setup of the ISR is realy weird.
You can't first call a sub from the ISR and then
just do "retfie" from the *sub*. You have to first
"return" from the sub back to the main ISR, then "retfie"
out of the ISR back to the non-interrupt code.

I think in this case that the retfie will not "return from
the interrupt", but work as a return from the sub
(and setting GIE which you probaly not want here).
Realy bad coding anyway...

You will probably get a stack overflow.

And what about those "in case" code parts ?
In *what* case ?

Several posters have sugested that a clean up of your
ISR code could be a good idea. Why not simply do that ?

Regards,
Jan-Erik.



2005\10\31@151652 by Debbie

flavicon
face

--- Jan-Erik Soderholm <jan-erik.soderholmspamKILLspamtelia.com> wrote:
>
> Your setup of the ISR is realy weird.
> You can't first call a sub from the ISR and then
> just do "retfie" from the *sub*. You have to first
> "return" from the sub back to the main ISR, then "retfie"
> out of the ISR back to the non-interrupt code.
>
Hmm. That's a point. retfie back to the loop from the return point below the
alert label? OK, thanks Jan-Erik -> will try it. Will check out Olin's
pre-processor also.
Debbie


               
____________________________________________________
Do you Yahoo!?
Take your Mail with you - get Yahoo! Mail on your mobile
http://au.mobile.yahoo.com/mweb/index.html

2005\10\31@161758 by Andy Armstrong

flavicon
face
On 31 Oct 2005, at 19:04, Debbie wrote:
> I guess in future it might be a better idea to keep the port  
> configs in-line
> with the main code, so they're easily visible.

Once they're right you'll just keep using the known good header  
though so in the long run it's probably better to keep them separate :)

--
Andy Armstrong, hexten.net


'[PIC] INTCON/OPTION REG Weird Symptom'
2005\11\01@123233 by Debbie
flavicon
face

--- Andy Armstrong <.....andyKILLspamspam.....hexten.net> wrote:>
> Once they're right you'll just keep using the known good header  
> though so in the long run it's probably better to keep them separate :)
>
> --
> Andy Armstrong, hexten.net

I'll say! Final(?) ver of the programme below. Calling the ISR as a subroutine
in its entirety ---> //bad idea//  :(  Saw it in a piclist example, thought it
was a good way to compact one's code. Changed my mind now. :| I'm building up a
lib of standard macros/subs that I tend to use all the time so I guess keeping
the main programme itself in a "standard form" is the way to go too.

Thankz guys!
Debbie

__CONFIG _CP_OFF & _WDT_OFF & _XT_OSC & _PWRTE_ON

        org       0x00
start    goto      main

        org       0x04  
intrpt:  
        goto      alert
;*********************************************************
;INCLUDED SUBROUTINES
;*********************************************************
include "can_dly.asm"          ;Delays for the IR wave train
include "ir_codes.inc"         ;MACROs for IR wave train.
     
;**********************************************************
;Main Programme  .. begin from upper half of Bank #0.
;**********************************************************
main:    
        clrw                   ; Make sure PIC OUTPTs are LOW, Set i/p's HIGH
                               ; => MAX232 o/p is LOW (inverted)
        movwf   PORTB
        clrw                   ;Set all PORTA low
        movwf   PORTA
        BANK_1
        movlw   CONFIG_B       ;See PIN ASSIGNMENTS
        movwf   TRISB
        movlw   CONFIG_A
        movwf   TRISA
        BANK_0
        clrf    FSR            
        IR_LED_OFF             ;Make sure the IR LED is OFF

;******************************************************************
;Configure the interrupts
;******************************************************************        
setint:
       BANK_1
       movlw    b'10011111'     ; Works with b7=1!
       movwf    OPTION_REG
       BANK_0
       PAGE_0
       movlw    b'00011000'     ;Disable interrupts for now. GIE=0
       movwf    INTCON  
   
      <.. clear registers etc ..>

loop:                           ;Get ready to watch ....

       <.. housekeeping subroutine calls ..>
       movf    PORTB,w         ;Read PORTB and then
       bsf     INTCON,GIE      ;Enable the interrupts
       nop
       sleep                   ;Shut down and wait for a bandit
       nop
       bcf     INTCON,GIE
       goto    loop            ;Go back to watch mode ...  

<..Inline subroutines - lots of ...>

;the interrupt handler, code now inline => NOT a subroutine!
alert:  
      PUSHSTATUS               ;Save current configuration
int_break01:                    ;Breakpoint for de-bugging

      <... isr code : calls subroutines from main programme.>

int_break02:                    ;End of ISR de-bug breakpoint
      POPSTATUS
      retfie
      end


               
____________________________________________________
Do you Yahoo!?
Listen to over 20 online radio stations and watch the latest music videos on Yahoo! Music.
http://au.launch.yahoo.com

2005\11\01@133903 by olin piclist

face picon face
Debbie wrote:
> I'm building up a
> lib of standard macros/subs that I tend to use all the time so I guess
> keeping the main programme itself in a "standard form" is the way to
> go too.

You can look at some of my "standard" templates at
http://www.embedinc.com/pic.

>         org       0x00

Really now.  Unless you've been a hermit in a cave for the last 5 years,
there is no excuse for still using archaic absolute mode.

> start    goto      main

OK on PICs with only one code page.  Beyond that you need to pay attention
to PCLATH.

>         org       0x04
> intrpt:
>         goto      alert

This is a waste of 2 cycles right where they are probably most important.
Some code will be at location 4, so why not make it the interrupt routine
and save the GOTO.  This will break on PICs with more than one code page
since PCLATH is unknown at the start of an interrupt and you can't do
anything about it right away (save W and STATUS first).


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\11\01@222820 by Debbie

flavicon
face

--- Olin Lathrop <EraseMEolin_piclistspam_OUTspamTakeThisOuTembedinc.com> wrote:>
You can look at some of my "standard" templates at
> http://www.embedinc.com/pic.

Hey thankz very much Olin!
>
> >         org       0x00
>
> Really now.  Unless you've been a hermit in a cave for the last 5 years,
> there is no excuse for still using archaic absolute mode.

Yep, I kinda figured I was bringing up the rear! :) Do you know any
websites/refs/books where the learner-driver can study up on mid to more
advanced pic programming? Stuff like directive language & relocatable code,
stuff like what's in the MPLAB manual? OK, I see what it says but  ... I dunno,
having trouble fitting into the overall mental picture. :( I'm sorta past the
newbie stage but still very much on the lower rungs.
Thankz - Debbie


               
____________________________________________________
Do you Yahoo!?
The New Yahoo! Movies: Check out the Latest Trailers, Premiere Photos and full Actor Database.
http://au.movies.yahoo.com

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