Searching \ for '[PIC]: port noise complaint' 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/ios.htm?key=port
Search entire site for: 'port noise complaint'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: port noise complaint'
2002\11\09@144607 by Rob Robson

picon face
This is my first posting (and my first microprocessor project in 18 years),
so I apologize in advance if I've overlooked something obvious in trying to
sort out the following vexing phantom port "noise" problem.  I've been
through the datasheet and the mid-range manual, but I'm stumped.

I'm using RB1-RB6 on a 4MHz 16F877 to detect six pushbutton closures, and
the other two inputs to detect active-low signals from a DAA and a DTMF
transceiver.  Port B is set as all inputs with the weak pull-ups enabled.
Port B serves no other function in this project, and so TRISB is left alone
after the following short initialization snippet:

   ; Port B initialization

CLRF         PORTB                  ; clear Port B output latches
BSF            STATUS,RP0         ; Bank 1
MOVLW    b'11111111'
MOVWF    TRISB                     ; set RB0-RB7 as all inputs

(and, later in the initialization...)

BSF             STATUS,RP0         ; Bank 1
MOVLW     b'00000001'            ; set Timer 0 prescale to 4 / enable Port
B pullups
MOVWF     OPTION_REG

I've set up Timer0 to interrupt on overflow every 1ms to create a system
'pulse' for resetting the external system supervisor, updating any non-zero
counters, etc.  No other interrupts are used.  My button-checking routine is
called every 73ms when its dedicated counter times out.  The problem
appeared as an endless series of random false button presses (or DAA/DTMF
chip _IRQ's...all 8 Port B lines exhibit this problem).  They were usually
getting filtered by the subsequent debounce routine, but the odd one squeaks
through and falsely triggers a subsequent legal-button-press routine (ouch).
The 'scope shows no noise whatsover on RB0-RB7.  I even put some 1k pullups
right on the PIC's socket and tried this with both the _RBPU options to no
effect.

To have a look at what was going on, I grabbed Port B and sent it out to
some LEDS on a TPIC6C595 via SPI and saw all kinds of random, rapid activity
(the SPI works fine, BTW: the same LED update routine normally gives me
solid, unflickering LEDs).  This is a snippet of the button-check routine
with my temporary LED test added:

Button_Check   ; called by Flag_Check (F5,1 set by Counter_PB_Chk)
BCF             STATUS,RP0
BCF             STATUS,RP1     ; Bank 0
BCF             FLAGS5,1          ; clear the button sample request timeout
flag
TSTF            PBDBNCE        ; debounce countdown in progress?
SKPZ
GOTO         _CHK_LTR         ; if so, go to check-back-later exit routine
below <not shown>
MOVFW     PORTB                ; if not, get buttons and ring signal
MOVWF     PBTEST               ; store button / ring data
COMF         PBTEST              ; convert to active-high
MOVFW      PBTEST              ; temp test: get the inverted Port B data...
MOVWF      LEDS                  ; ...and send it out to the LEDS for
viewing
BCF             PBTEST,7           ; mask off DTMF _IRQ bit
TSTF            PBTEST
SKPNZ                                   ; any active?
GOTO         _CHK_LTR         ; if not, go to check-back-later exit routine
MOVFW     PBTEST              ; get inverted button / ring data
MOVWF     BUTTONS          ; store byte in button data holding register
<etc.>

The obvious question is, WHAT GIVES???  Why would I be seeing a bunch of
activity on Port B that shouldn't be there?  What kinds of things should I
be looking for in my code that might be causing this?  I think I've
eliminated all possible hardware causes: I've tried three different
16F877's, including a 20MHz one to be sure I wasn't looking at a 'bad batch'
issue.  For the record, there is no ICD...just me (kind of a hardware guy) ,
MPLAB 5.50, a PICSTART Plus, and a receding hairline.

Any and all ideas or suggestions would be welcome beyond measure.  Even a
round of embarrassing anti-newbie chastising would be a gift at this point,
if it came bundled with some sort of revelation as to what I might be doing
wrong.

Thanks in advance,
Rob Robson
Kelowna, BC, Canada

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\11\09@155657 by Russell McMahon

face
flavicon
face
Welcome to the asylum..
Your first post seems to pass the newbie/Olin test suite.

Quick thought (pre rushing to shower and out the door) - if you run your
button check routine NON interrupt with a soft timing loop, does it work OK.

Are IRQs off when you are playing with in input line i/o status?

       RM

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\11\09@171049 by Jinx

face picon face
> I've set up Timer0 to interrupt on overflow every 1ms to create a
> system 'pulse' for resetting the external system supervisor, updating
> any non-zero counters, etc.  No other interrupts are used.  My
> button-checking routine is called every 73ms when its dedicated
> counter times out.  The problem appeared as an endless series
> of random false button presses

You say "random" but are the noise spacings multiples of 1ms or
73ms ? The actual T0 IRQ looks to be 1,000,000 / 4 / 256 = 976us.
Is that clashing with the 73ms routine somehow ? Are you context
saving / restoring in the ISR ?

===================================================

Love the Subject btw, very clever. You sure you haven't got a bunch
of sexually dysfunctional chips who are just noisy boys?

http://www.inkblotsmag.com/critiques/literature/portnoy.html

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\11\09@184934 by Rob Robson

picon face
Thanks very, very much for the response.

> You say "random" but are the noise spacings multiples of 1ms or
> 73ms ? The actual T0 IRQ looks to be 1,000,000 / 4 / 256 = 976us.
> Is that clashing with the 73ms routine somehow ? Are you context
> saving / restoring in the ISR ?
>
I really can't tell the extent of the "randomness": my dinosaur scope only
indicates that the weirdness is not periodic.

Here's my ISR.  I'm fairly sure I've covered all the bases, but I'm new to
this.  Pick away.

Pulse                                            ; called every 1.0ms on
Timer0 timeout
                                                   ; note to self: must be
<900 instructions total (incl. worst-case sub/rt's)
BCF             INTCON,T0IF       ; clear Timer 0 interrupt flag
BSF             INTCON,T0IE       ; re-enable Timer 0 interrupt (if
necessary)
BCF             STATUS,RP0
BCF             STATUS,RP1         ; Bank 0
MOVLW     d'008'                      ; reset Timer 0 by reloading TMR0 reg
MOVWF      TMR0                      ; FFh-248d=8d (req'd for 1.00ms
overall Timer 0 rate)
MOVWF      W_TEMP                ; save W contents during ISR
SWAPF        STATUS,W             ;
CLRF            STATUS                 ; select Bank 0 and clear IRP
MOVWF       STATUS_TEMP     ; save status to Bank 0 temp reg
MOVF         PCLATH,W                     ;
MOVWF     PCLATH_TEMP        ; save PCLATH in temp reg
BTFSC         FLAGS3,4                 ; test the "Initialization In
Progress" flag
GOTO         _EXIT_PULSE           ; if it's set, bypass all the usual
routines
<"the usual routines"=a list of calls to short counter update routines (left
out for brevity)>
_EXIT_PULSE
CALL           Supervisor                   ; prevent system supervisor
from causing a reset
BCF             STATUS,RP0
BCF             STATUS,RP1              ; select Bank 0
MOVF         PCLATH_TEMP,W     ; restore PCLATH
MOVWF     PCLATH                      ;
SWAPF       STATUS_TEMP,W     ; set STATUS reg to its original state...
MOVWF     STATUS                      ; ...and put it back where it goes
SWAPF       W_TEMP,F                 ; engage in some chicanery...
SWAPF        W_TEMP,W               ; ...to restore W
RETFIE                                            ; return and re-enable
interrupts

> ===================================================
>
> Love the Subject btw, very clever. You sure you haven't got a bunch
> of sexually dysfunctional chips who are just noisy boys?

Perhaps.  Would this do the trick, then?
MOVFW    _DYSFUNC
SKPZ
CALL        Water_Cannon
<etc.>

Rob Robson

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\11\09@191455 by Jan-Erik Soderholm

face picon face
If I'm not mistaken here, you are always saving d'008' to
W_TEMP, not ? Should not "MOVWF      W_TEMP" come
*before*  "MOVLW     d'008'" ? Something like this :

MOVWF      W_TEMP                ; save W contents during ISR
SWAPF        STATUS,W             ;
MOVWF       STATUS_TEMP     ; save status to Bank 0 temp reg
MOVF         PCLATH,W                     ;
MOVWF     PCLATH_TEMP        ; save PCLATH in temp reg
;
CLRF            STATUS                 ; select Bank 0 and clear IRP
MOVLW     d'008'                      ; reset Timer 0 by reloading TMR0 reg
MOVWF      TMR0                      ; FFh-248d=8d (req'd for 1.00ms overall Timer 0 rate)


Jan-Erik Svderholm
S:t Anna Data
Sweden


> MOVLW     d'008'                      ; reset Timer 0 by reloading TMR0 reg
> MOVWF      TMR0                      ; FFh-248d=8d (req'd for 1.00ms overall Timer 0 rate)
> MOVWF      W_TEMP                ; save W contents during ISR
> SWAPF        STATUS,W             ;
> CLRF            STATUS                 ; select Bank 0 and clear IRP
> MOVWF       STATUS_TEMP     ; save status to Bank 0 temp reg
> MOVF         PCLATH,W                     ;
> MOVWF     PCLATH_TEMP        ; save PCLATH in temp reg

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\11\09@191459 by Rob Robson

picon face
> Welcome to the asylum..
> Your first post seems to pass the newbie/Olin test suite.

Whew.

> Quick thought (pre rushing to shower and out the door) - if you run your
> button check routine NON interrupt with a soft timing loop, does it work
OK.

Please forgive my slowness, but I'm not sure I follow you.  All my timing is
based on a 1ms Timer0 overflow interrupt...the button check routine just
reloads its own counter with d'73' every time it's called.  Are you
suggesting I cobble together a little delay routine based on processor
cycles and use _that_ to call the button check?

> Are IRQs off when you are playing with in input line i/o status?

Good question.  I believe they are.  My initialization loads INTCON with
b'10100000', which should enable Global Interrupts (GIE) and the Timer 0
overflow interrupt (T0IE), and disable the Port B interrupt-on-change, the
RB0 external interrupt, and all the peripheral interrupts (according to
DS30292C p20).

Please keep throwing me these questions...anything to help me sort this
blasted thing out.

Rob Robson

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\11\09@194028 by Jinx

face picon face
> If I'm not mistaken here, you are always saving d'008' to
> W_TEMP, not ? Should not "MOVWF      W_TEMP" come
> *before*  "MOVLW     d'008'" ? Something like this :

And you'll probably need to tinker with that reload value slightly
to account for all ICs used before the value actually gets into the
TMR0 register

http://www.piclist.com/techref/microchip/timer.htm

You only need to clear T0IF. T0IE is still set during the ISR but
GIE is not

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\11\09@200936 by Olin Lathrop

face picon face
> Here's my ISR.  I'm fairly sure I've covered all the bases, but I'm new to
> this.  Pick away.
>
> Pulse                                            ; called every 1.0ms on
> Timer0 timeout
>                                                     ; note to self: must
be
> <900 instructions total (incl. worst-case sub/rt's)
>  BCF             INTCON,T0IF       ; clear Timer 0 interrupt flag
>  BSF             INTCON,T0IE       ; re-enable Timer 0 interrupt (if
> necessary)

It is pointless to disable then immediately re-enable the timer 0 interrupt.

>  BCF             STATUS,RP0
>  BCF             STATUS,RP1         ; Bank 0

This corrupts STATUS before it is saved.  It has the effect of randomly
trashing the bank bits in the foreground code (it hates that).

>  MOVLW     d'008'                      ; reset Timer 0 by reloading TMR0
reg

This randomly trashes W from the foreground code's point of view (it really
hates that).  Very bad unless your foreground code is the equivalent of "10
GOTO 10".

>  MOVWF      TMR0                      ; FFh-248d=8d (req'd for 1.00ms
> overall Timer 0 rate)

It is better to add a value into timer 0 during the interrupt than to reset
it to a fixed value.  The add is independent of relative position from the
start of the interrupt, and accumulates no long term error due to interrupt
jitter, disabled interrupts, etc.  Check the manual about timer 0 stopping
for a few cycles after it is written to.

While there is nothing wrong with using timer 0 to generate a periodic
interrupt, it is easier to use timer 2 and its period register if you are
using a machine that has timer 2.

>  MOVWF      W_TEMP                ; save W contents during ISR

Too late, W already contains 8.

>  SWAPF        STATUS,W             ;
>  CLRF            STATUS                 ; select Bank 0 and clear IRP
>  MOVWF       STATUS_TEMP     ; save status to Bank 0 temp reg
>  MOVF         PCLATH,W                     ;
>  MOVWF     PCLATH_TEMP        ; save PCLATH in temp reg
> .
> .
> .

You need to carefully read the section about interrupts and how to
save/restore state in the ISR.  PICs don't do anything special on an
interrupt except to clear INTCON,GIE and CALL 4.  The rest is left as an
exercise to the coder.  You have to save/restore everything you use in
software including W and STATUS.  This is a little tricky since everything
uses W, including any method of saving STATUS, but you can't set the bank
without altering STATUS.

I have a template interrupt routine and lots of other stuff at
http://www.embedinc.com/pic.  Take a look at QQQ_INTR.ASPIC.  It is an
example of the right way to get into and out of an interrupt.  It also
automatically saves/restores PCLATH if running on a machine with more than
one code page, and lets you set an assembly time switch to save/restore FSR
in case your interrupt routine uses FSR.


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

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\11\09@201141 by Olin Lathrop

face picon face
> And you'll probably need to tinker with that reload value slightly
> to account for all ICs used before the value actually gets into the
> TMR0 register

Even better, add a value into timer 0 instead of restting it.  See my other
post.


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

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\11\09@201805 by Olin Lathrop

face picon face
> >  BCF             INTCON,T0IF       ; clear Timer 0 interrupt flag
> >  BSF             INTCON,T0IE       ; re-enable Timer 0 interrupt (if
> > necessary)
>
> It is pointless to disable then immediately re-enable the timer 0
interrupt.

I just got my response back for the server and noticed that you are actually
clearing the flag and attempting to re-enable the interrupt.  Sorry I didn't
notice that before.

On a PIC an interrupt never disables the individual interrupt that caused
the condition.  The PIC only disables interrupts globally by resetting the
GIE bit in INTCON (at least that's how the PIC 16 works, other families have
different wrinkles).  You therefore don't need to set the T0IE bit because
it is still set.  You do however need to reset the TOIF bit (as you did)
because otherwise you would get an immediate interrupt when interrupts are
re-enabled by the RETFIE instruction at the end of the interrupt service
routine.


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

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\11\10@020014 by Rob Robson

picon face
Enormous thanks to all who responded and helped me sort out my dog's
breakfast of an ISR.  It's amazing that anything worked at all, what with W
being trashed so often.  It's now blatantly obvious the port itself was
fine, but was only being observed (as is virtually everything) via the
abused accumulator.  When the revised code ran flawlessly, I felt like
buying a Volvo.  Thanks for being so generous with your time and expertise,
Jan-Erik, Olin, Jinx and Russell.

Rob Robson

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


2002\11\10@021504 by Sean Alcorn - PIC Stuff

flavicon
face
Rob,

> Thanks for being so generous with your time and expertise,
> Jan-Erik, Olin, Jinx and Russell.

They always are - just some of the Gurus of the list. Glad to hear that
your code worked out, but please don't do anything rash, like buying a
Volvo! :-)

Regards,

Sean

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


2002\11\10@030520 by Jinx

face picon face
> buying a Volvo.  Thanks for being so generous with your time and
> expertise, Jan-Erik, Olin, Jinx and Russell.
>
> Rob Robson

You're welcome (and cheers Sean). It's easy to forget sometimes
that micros are really dumb. They only do what we tell them to eh ?

>
> > Love the Subject btw, very clever. You sure you haven't got a
> > bunch of sexually dysfunctional chips who are just noisy boys?

> Perhaps.  Would this do the trick, then?
> MOVFW    _DYSFUNC
> SKPZ
> CALL        Water_Cannon
> <etc.>

MOVF      HANDS,W
MOVWF  BOXING_GLOVES
BED

BED MACRO

HANDS_ABOVE_THE_COVERS
SLEEP

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


2002\11\11@050209 by Alan B. Pearce

face picon face
>BED MACRO
>
>HANDS_ABOVE_THE_COVERS
>SLEEP

Ahh yes, but is his beard over or under the sheet :))

(See the stories of Tintin, I think it is Red Rackhams Treasure, but could
be another one of them )

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


2002\11\11@113034 by Mike Mansheim

flavicon
face
Rob Robson wrote:
> When the revised code ran flawlessly, I felt like buying a Volvo.

At this risk of proving cluelessness, I don't get this reference.
Can you explain?

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


2002\11\11@145853 by Rob Robson

picon face
> Rob Robson wrote:
> > When the revised code ran flawlessly, I felt like buying a Volvo.
>
> Mike Mansheim wrote:
> At this risk of proving cluelessness, I don't get this reference.
> Can you explain?
>
It was a reference to the (presumed) ethnicity of two of the problem-solving
respondents, and an even more obscure reference to "dum volvo video disco",
which has been loosely translated as "As I turn, I see and learn."  Not
exactly rolling-around-on-the-floor-clutching-your-sides stuff, but I was
too giddy to see my code finally working to have come up with anything
better.

Rob Robson

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


2002\11\11@171144 by Russell McMahon

face
flavicon
face
> > > When the revised code ran flawlessly, I felt like buying a Volvo.
> >
> > Mike Mansheim wrote:
> > At this risk of proving cluelessness, I don't get this reference.
> > Can you explain?
> >
> It was a reference to the (presumed) ethnicity of two of the
problem-solving
> respondents, and an even more obscure reference to "dum volvo video
disco",
> which has been loosely translated as "As I turn, I see and learn."  Not
> exactly rolling-around-on-the-floor-clutching-your-sides stuff, but I was
> too giddy to see my code finally working to have come up with anything
> better.

Presumably Jinx's allusion to "Portnoy's Complaint" (Google for that) was
either totally obvious to all or has been totally missed. I'm still
wondering if that subject line was a clever (albeit irrelevant) pun or a
complete fluke.



                   RM

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


2002\11\11@173255 by Rob Robson

picon face
> Presumably Jinx's allusion to "Portnoy's Complaint" (Google for that) was
> either totally obvious to all or has been totally missed. I'm still
> wondering if that subject line was a clever (albeit irrelevant) pun or a
> complete fluke.
>
>
>
>                     RM

It's what happens when artsies become programmers.

RR

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


2002\11\11@222900 by Rich

picon face
I did pick up the subtle allusion to Portnoy's Complaint.  I wondered how
many would.  I did think it was very clever!

Rich


{Original Message removed}

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