Searching \ for '[PIC]: Missing GPIF occasionally' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'Missing GPIF occasionally'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Missing GPIF occasionally'
2003\04\09@222613 by Dale Botkin

flavicon
face
Hi guys,

I have a 12F629 app using GPIF to wake the processor up from SLEEP.  I
have weak pullups turned on and IOCB set properly for the pins I want to
use for wake-up.  I read PORTA, clear GPIF and go to sleep.  One more
inputs are momentarily grounded to wake up the proc.  Here's the sleep
code:

.................... void input_sleep(void) {
....................     char x;
....................
....................     x = input_a();
*
0191:  MOVF   05,W
0192:  MOVWF  3C
....................     bit_clear(INTCON,0);
0193:  BCF    0B.0
....................     sleep();
0194:  SLEEP
0195:  RETLW  00

(Yes, I know there's an extra instruction in there I don't need at 0192.)

So 99.9% of the time it works perfectly.  Once in a blue moon, though,
seemingly at random, it fails to wake up when an input goes low.  It does
not seem to happen to one input more than the other.  I can't find
anything in the data sheet to indicate a potential cause; there is a note
saying that if the input pin changes at the start of the Q2 clock cycle
the GPIF flag may not get set.  OK, but the PIC is always sleeping when
this happens, so there is no Q2.

The PIC runs on its internal 4MHz oscillator, roughly 3V battery supply,
room temperature, no unusual loads on output pins.

Anyone see something I've overlooked?  It's perplexing.

Dale
--
It's a thankless job, but I've got a lot of Karma to burn off.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\04\10@133535 by Dwayne Reid

flavicon
face
At 09:24 PM 4/9/03 -0500, Dale Botkin wrote:

>I have a 12F629 app using GPIF to wake the processor up from SLEEP.  I
>have weak pullups turned on and IOCB set properly for the pins I want to
>use for wake-up.  I read PORTA, clear GPIF and go to sleep.  One more
>inputs are momentarily grounded to wake up the proc.  Here's the sleep
>code:
>
>So 99.9% of the time it works perfectly.  Once in a blue moon, though,
>seemingly at random, it fails to wake up when an input goes low.

I have recollection of needing to place a NOP right after the sleep
instruction.  Don't remember the reason or which family had this
requirement.  But it might be worth investigating.

dwayne


--
Dwayne Reid   <spam_OUTdwaynerTakeThisOuTspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 19 years of Engineering Innovation (1984 - 2003)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

2003\04\10@142421 by Rick Regan

picon face
>I have recollection of needing to place a NOP right
>after the sleep
>instruction.  Don't remember the reason or which
>family had this
>requirement.  But it might be worth investigating.

Here's an excerpt from the 16F84A datasheet of what
you're probably referring to:

"While the SLEEP instruction is being executed, the
next instruction (PC + 1) is pre-fetched. For the
device to wake-up through an interrupt event, the
corresponding interrupt enable bit must be set
(enabled). Wake-up occurs regardless of the state of
the GIE bit. If the GIE bit is clear (disabled), the
device continues execution at the instruction after
the SLEEP instruction. If the GIE bit is set
(enabled), the device executes the instruction
after the SLEEP instruction and then branches to the
interrupt address (0004h). In cases where the
execution of the instruction following SLEEP is not
desirable, the user should have a NOP after the
SLEEP instruction."

The question is, when would the execution of the
instruction following SLEEP not be "desirable?"

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

2003\04\10@144112 by Dale Botkin

flavicon
face
On Thu, 10 Apr 2003, Dwayne Reid wrote:

> >So 99.9% of the time it works perfectly.  Once in a blue moon, though,
> >seemingly at random, it fails to wake up when an input goes low.
>
> I have recollection of needing to place a NOP right after the sleep
> instruction.  Don't remember the reason or which family had this
> requirement.  But it might be worth investigating.

Good point, so I did investigate.  The PIC preloads the instruction
following the SLEEP instruction before going to sleep, so upon wakeup that
instruction is executed before an interrupt will be serviced.  If you
don't want that to happen you need a NOP after the SLEEP.

In my case, I am using the GPIF interrupt with GIE disabled; this wakes
the PIC from sleep, but there is no interrupt.  According to the data
sheet, this would not need a NOP.  The instruction immediately following
the SLEEP instruction is a RETLW, which would execute normally and the
input would be tested a few instructions later.  I'll try it anyway,
though, just in case.  I will say this has given me another excuse to go
through the port hardware diagrams and several parts of the data sheet in
great detail, again.

Dale
--
It's a thankless job, but I've got a lot of Karma to burn off.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2003\04\10@144322 by Dale Botkin

flavicon
face
On Thu, 10 Apr 2003, Rick Regan wrote:

> The question is, when would the execution of the
> instruction following SLEEP not be "desirable?"

If you're using an interrupt to wake up and have an ISR you want executed
before anything else happens.

Dale
--
It's a thankless job, but I've got a lot of Karma to burn off.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2003\04\10@150232 by Rick Regan

picon face
{Quote hidden}

Does the change definitely occur AFTER the sleep?
If it occurred just before the sleep, wouldn't
you be clearing the GPIF that should be waking you up?

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2003\04\10@165308 by Dale Botkin

flavicon
face
On Thu, 10 Apr 2003, Rick Regan wrote:

> Does the change definitely occur AFTER the sleep?
> If it occurred just before the sleep, wouldn't
> you be clearing the GPIF that should be waking you up?

Absolutely.  The sleep occurs after all inputs have been high, and the
next input is not occurring for some random period but not less than a few
tens of milliseconds after the chip goes to sleep -- it's a
human-activated input.

Dale
--
It's a thankless job, but I've got a lot of Karma to burn off.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\04\11@022830 by Jason Harper

picon face
Dale wrote:
> Absolutely.  The sleep occurs after all inputs have been high, and the
> next input is not occurring for some random period but not less than a
few
> tens of milliseconds after the chip goes to sleep -- it's a
> human-activated input.

If the device is put to sleep by a human action as well, is it possible
that the switch is still bouncing when SLEEP is executed?
       Jason Harper

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu>

2003\04\11@035954 by erholm (QAC)

flavicon
face
In the PICUART.ASM document/source by T. McGahee, there
is discussion about clearing GIE by doing like this :

goe01   bcf    intcon, gie
       btfsc  intcon, gie
       goto   gie01

Se the document for the reason to do this. It has something
to do with an interupt occuring *during* the execution of
the BCF intruction.

I'm not sure this is related to the problem at hand, thought...

Jan-Erik Soderholm.

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu>

2003\04\11@042514 by Alan B. Pearce

face picon face
>In the PICUART.ASM document/source by T. McGahee, there
>is discussion about clearing GIE by doing like this :
>
>goe01   bcf    intcon, gie
>        btfsc  intcon, gie
>        goto   gie01
>
>Se the document for the reason to do this. It has something
>to do with an interupt occuring *during* the execution of
>the BCF intruction.
>
>I'm not sure this is related to the problem at hand, thought...

I believe the later PIC chips have this bug fixed. However it does not
bother me because I use Olin's development environment which has a macro
that takes care of this if it is a PIC with that problem :)) But then I am
not the poster of the original problem.

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu>

2003\04\11@075133 by Olin Lathrop

face picon face
> In the PICUART.ASM document/source by T. McGahee, there
> is discussion about clearing GIE by doing like this :
>
> goe01   bcf    intcon, gie
>         btfsc  intcon, gie
>         goto   gie01
>
> Se the document for the reason to do this. It has something
> to do with an interupt occuring *during* the execution of
> the BCF intruction.

Some 16 family PICs had a bug where an interrupt could be taken right
after the GIE bit was cleared by BCF INTCON,GIE.  The RETFIE at the end of
the interrupt routine would re-enable interrupts.  The net effect is that
BCF INTCON,GIE disabled interrupts most of the time but not always.  The
workaround was to test the bit and try to clear it again if it was still
set.

See my INTR_OFF macro in STD.INS.ASPIC at http://www.embedinc.com/pic.  It
emits the workaround code on those chips with the bug, and a simple BCF
INTCON,GIE on others.  It also handles the different details of disabling
interrupts on the 17 and 18 family.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu>

2003\04\11@084607 by

flavicon
face
Well, I actualy downloaded your dev environment just
the other day. Maybe I'll give it a try this weekend.
It was the completed support from the 18-series that
made the decision.

Jan-Erik.

Olin Lathrop wrote:

> See my INTR_OFF macro in STD.INS.ASPIC at http://www.embedinc.com/pic.  It
> emits the workaround code on those chips with the bug, and a simple BCF
> INTCON,GIE on others.  It also handles the different details of disabling
> interrupts on the 17 and 18 family.

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamTakeThisOuTmitvma.mit.edu>

2003\04\11@105735 by Dale Botkin

flavicon
face
On Fri, 11 Apr 2003, Jason Harper wrote:

> Dale wrote:
> > Absolutely.  The sleep occurs after all inputs have been high, and the
> > next input is not occurring for some random period but not less than a
> few
> > tens of milliseconds after the chip goes to sleep -- it's a
> > human-activated input.
>
> If the device is put to sleep by a human action as well, is it possible
> that the switch is still bouncing when SLEEP is executed?
>         Jason Harper

Nope, but I think I may have figured it out.  The PIC goes to sleep and is
woken up by a change on one or more inputs, at which point it looks at the
contact inputs to see which one(s) are active.  If it finds none, it goes
back to sleep.  My theory is that if there is some contact bounce at just
the wrong time, the PIC will not see the input and will (apparently)
ignore it.

So I now use a timer.  In the routine that handles the contact inputs, if
none are found active TIMER0 is cleared.  The PIC will loop looking at the
inputs for a contact closure until TIMER0 overflows.  This way the sleep
is delayed as much as 4ms or so, which seems to be enough time to remedy
the situation since I have not been able to get it to fail yet.  This
provides some debounce when needed, but doesn't burn much code space (I
think it was about 4-5 words) and doesn't add some fixed debounce delay to
contact inputs, which would be a bad thing in this particular case.

Thanks to all who replied.

Dale
--
It's a thankless job, but I've got a lot of Karma to burn off.

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam.....mitvma.mit.edu>

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