'External resetting of OUTPUT pins.'
Although it is not clear to me from Microchips' discussion of
"Bidirectional I/O Pins" it seems the following can occur.
If an OUTPUT pin sees noise that opposes its assigned state
(1 or 0) at exactly the moment its' port is involved in a
read-modify-write cycle then the 'wrong' state gets latched
in the port buffer and becomes the (permanent) new state.
Microchip discussed this for a INPUT pin but to my mind
on a PIC (or similar) an OUTPUT pin is just another INPUT
pin 'with an attitude' (measured by its output (or drive) impedance).
I have not done the test (busy NOT lazy) of forcing this at risk
of the chip. But if it CAN occur it can be a real problem. It
seems to be happening on a very noisy system I'm currently
debugging. I'd like any theory (or better experience) on this
from you all. For instance there may be more silicon at the I/O
ports than the block diagram indicates.
<I know, I should fix the noise, but that is not always the most
immediate cure> I think I'll add some code to see if my
ports change on their own. By segregating OUTPUT pins to
their own 'write only by byte' port, my problems seem to improve, for
whatever that proves.
At 07:42 AM 3/6/99 -0800, you wrote:
I am very interested in this, because I'm debugging a new product.
Under deliberate attack by a noise source - to determine how
robust the product is - particular registers get corrupted, but
not others. Is that what you are experiencing?
I'm using the 16C54C at 2mHz.
Richard Martin wrote:
> If an OUTPUT pin sees noise that opposes its assigned state
> (1 or 0) at exactly the moment its' port is involved in a
> read-modify-write cycle then the 'wrong' state gets latched
> in the port buffer and becomes the (permanent) new state.
If the noise on an output pin is so severe that it temporarily
'overrides' the real data state of an output pin then obviously the PIC
will read the dominating pin state and rewrite this data back to the
Best thing to do is get rid of the noise, if possible, or use a 'mirror'
register to manipulate the data so it doesn't get corrupted.
You may even need to continually rewrite data to the port and tris regs
as well to keep them in a known state.
PicNPoke - Multimedia 16F84 Beginners PIC Tools.
|Tony Nixon wrote:
On a similar project, here's part of the problem I experienced; I'll
ask as this may be the sort of thing that goes on on PIC projects as
You inherit someone else's project; They route power and ground, um,
"rather eclectically" (i.e. about 8 mil traces for all signals, on a
single sided PCB, including Ground and Vss/Vdd, so "ground" and "vcc"
are "Sorta Ground" and "Sorta Vcc".) To say that it acted unusually,
would be understated.
What's the best approach on PIC projects to fix this sort of
situation, to get a prototype running? On mine (Oh, 1987 or so? 74HS
series and 40xx series logic plus a couple op amps in there, etc.) I got
mad & just "Brute Force'd it" - cut power and ground "bus" traces off
the board by each IC, ran "REAL" power and ground buses with superglue &
#18 wire  on the solder side, to each IC, and added in 0.1uF MilCer
despiking caps where missing (i.e. at most every IC.) I know, the BEST
way's to run screaming, or if you're not able to escape, to re-make the
entire PC board, but what about where you cannot do that? (I cannot say
the guy I did that for, LIKED it - at first; He did stop complaining
when he tried it out & it wasn't flakey anymore, he ended up having a
different person do a production PCB (much better done production run
board, too.) Guess educating him on WHY I'd done what I did, worked
<G> (Good engineer, new out of college though, didn't know 10 turn pots
existed, etc. Experience helps, doesn't it?) I don't claim to have
solved this ELEGANTLY, at all, here...
 When I say brute force, I mean brute force <G> Had tantalum's on
the power bus, too, at the intake end. Wanted to see what the thing
worked like when it had clean power, not Vcc= somewhere between 3.4 and
5.5 volts, usually 4.7 volts, roughly...
More... (looser matching)
- Last day of these posts
- In 1999
, 2000 only
- New search...