I have some code I wrote a long time ago and reactivated now. It has a weird
RBPU problem. Description:
The code is for 16F84A (no discussion on this please), it sets PORTB RB0 and RB1
as inputs, turns on _RBPU, and writes xxxxxx11 into PORTB. This is to turn on
pullups and allow 2 tact switches to be read. This works, but later, while the
program runs, the xxxxxx11 becomes xxxxxx00 somehow. I am sure I am missing
something but none of the simulators I used duplicate the problem.
So, assuming that:
- PORTB is always in tris mode 00000011
- OPTION _RBPU is set to 0 and never changed
- all writes to PORTB write 11 into RB0 RB1
WHAT can change the RB0 RB1 to 0s and turn off the pullups?
The accesses to PORTB are of the following types:
1. ...
iorwf Fbflags,w ; temp register which has 11 in its lower bits, always, checked
movwf PORTB
2. movf Fbflags,w ; as above
iorwf PORTB,f
3. movf PORTB,w ; pure read
andlw SW_MASK ...
4. bsf PORTB,SOMEBIT ; other than 0 or 1
nop
bcf PORTB,SOMEBIT
Which one of these is suspect of resetting the PORTB output bits RB0 and RB1, do
you think? Also, none of the sims I have reproduce the PORTB written as xxxxxx11
correctly when its 0,1 pins are inputs. There should be a display for the write
latch and another for the read latch, I think?
> WHAT can change the RB0 RB1 to 0s and turn off the pullups?
>
> The accesses to PORTB are of the following types:
>
> 1. ...
> iorwf Fbflags,w ; temp register which has 11 in its lower bits, always, checked
> movwf PORTB
>
> 2. movf Fbflags,w ; as above
> iorwf PORTB,f
>
> 3. movf PORTB,w ; pure read
> andlw SW_MASK ...
>
> 4. bsf PORTB,SOMEBIT ; other than 0 or 1
> nop
> bcf PORTB,SOMEBIT
>
> Which one of these is suspect of resetting the PORTB output bits RB0 and RB1, do you
> think? Also, none of the sims I have reproduce the PORTB written as xxxxxx11
> correctly when its 0,1 pins are inputs. There should be a display for the write
> latch and another for the read latch, I think?
This sounds like a read/modify/write problem happening while a switch is pressed, or a bank select problem when things should be writing to the PORT it writes to the TRIS instead.
Both hard to catch. The first one would be almost impossible to simulate, which may be why it doesn't appear when you simulate things.
-- Scanned by iCritical.
> I have some code I wrote a long time ago and reactivated now. It has a
> weird
> RBPU problem. Description:
>
> The code is for 16F84A (no discussion on this please), it sets PORTB RB0
> and RB1
> as inputs, turns on _RBPU, and writes xxxxxx11 into PORTB. This is to turn
> on
> pullups and allow 2 tact switches to be read. This works, but later, while
> the
> program runs, the xxxxxx11 becomes xxxxxx00 somehow. I am sure I am missing
> something but none of the simulators I used duplicate the problem.
>
>
I don't think the 84a has a separate output latch. So writing pins on PORTB
that are set to tristate has no effect. What is the voltage on RB0 and RB1
when PORTB reads 0 for those pins?
> So, assuming that:
> - PORTB is always in tris mode 00000011
> - OPTION _RBPU is set to 0 and never changed
> - all writes to PORTB write 11 into RB0 RB1
>
> WHAT can change the RB0 RB1 to 0s and turn off the pullups?
>
> The accesses to PORTB are of the following types:
>
> 1. ...
> iorwf Fbflags,w ; temp register which has 11 in its lower bits, always,
> checked
> movwf PORTB
>
> 2. movf Fbflags,w ; as above
> iorwf PORTB,f
>
> 3. movf PORTB,w ; pure read
> andlw SW_MASK ...
>
> 4. bsf PORTB,SOMEBIT ; other than 0 or 1
> nop
> bcf PORTB,SOMEBIT
>
> Which one of these is suspect of resetting the PORTB output bits RB0 and
> RB1, do
> you think? Also, none of the sims I have reproduce the PORTB written as
> xxxxxx11
> correctly when its 0,1 pins are inputs. There should be a display for the
> write
> latch and another for the read latch, I think?
>
> tia,
>
> -- Peter
>
>
>
>
> I don't think the 84a has a separate output latch. So writing pins on PORTB
> that are set to tristate has no effect. What is the voltage on RB0 and RB1
> when PORTB reads 0 for those pins?
Mark, all pics have a separate output latch, please refer to the PORTB latch
description in the datasheet, there is a neat schematic.
Russel may be right here, I also suspect a rmw problem, but how? Again, the
accesses to PORTB are few and can be resumed to:
1. bsf/bcf one bit, which is set as output
2. iorwf PORTB,f with a byte which has 11 as lsbs
3. movwf PORTB which always has 11 as lsbs
4. movf PORTB,w which should not change the output latch at all?
So which one of these is suspect of rmw problem?
Anyway I will rewrite the code to remove the bsf/bcf parts which are highly
suspect. Note that I have no load on the pins at all, they are floating (RB0 and
RB1), and are only grounded when the tact switches close. There is no debouncing
cap on the prototype board (yet). This should not happen [tm], but, hey...
> Russel may be right here, I also suspect a rmw problem, but how? Again, the
> accesses to PORTB are few and can be resumed to:
>
> 1. bsf/bcf one bit, which is set as output
That might well be your smoking gun.
Rule of thumb: the only instructions that write to a PORT that has more than one bit set as output should be MOVWF instructions.
Okay, I nailed it, RBPU was being turned off by yet another option setting, that
one with RBPU set to '1'... I was sure there was only 1 in the code, so sure
that I did not check that... duh. Maintaining 1000LOC+ requires iron discipline.
Thanks for the hand holding, meanwhile I made the code rmw safe too, since I was
at it.
One more thing: gpsim DID catch the glitch but I did not look at the right
place. Turn on the 'breadboard' and the IO pins on the pic turn red (high) when
input and RBPU on, and green when RBPU off (pins '0').
>4. bsf PORTB,SOMEBIT ; other than 0 or 1
> nop
> bcf PORTB,SOMEBIT
>
>Which one of these is suspect of resetting the PORTB output bits RB0 and RB1,
>do you think? Also, none of the sims I have reproduce the PORTB written as
> xxxxxx11 correctly when its 0,1 pins are inputs. There should be a display for
> the write latch and another for the read latch, I think?
If some pins within a port are tri-stated, and you perform a Read-Modify-Write operation on that port (such as the BSF/BSF instruction), then the output latches for the tri-stated pins will be modified (they will get set to the logic level applied to the pin). To avoid this you will need to perform your R-M-W operations on a shadow variable and then write the entire byte to the port.
Mike
=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
mit.edu [.....piclist-bouncesKILLspam