Exact match. Not showing close matches.
'[PIC] Reading a Port issue with 16F877A'
I have a small problem with a big impact on my application.
I am using a 16F877A, running in a 5V environment with 10 MHz.
I am using a timer interrupt (with 25ms) to read PORTB, Bit5. This pin is
defined as input. There is no write at all to this pin by software.
The internal pull-up is disabled. I am using an external pull-up to 5V. This
pin is connected to an external electronic (PS_ON_m Signal from a computer
When the incoming signal is high, I am always reading a high (1) on this pin
by software. I have never seen, that a low was reed, when high was attached
to this pin.
But when the signal is low, it happens, that from time to time, this pin is
read as 1 instead of 0. I supervised the line with an osci, and I never saw
a glitch or spike or whatever. To be shure, I connected the pin direct to
GND. But again, from time to time, I read a wrong values. This may happen
after 30 seconds fro start or even after 20 minutes.
Well, we first build this application 18 month ago, and we never saw this
happen(with exactly the same firmware and revision number of the PIC. Now,
we had to build new boards, and now we have this issues.
I first though, we could could have a problem with the pic itself, so we
checked for datecodes. The very first (we no issue) had been from 2006, the
failing ones had been from 2007. So we decided to replace the pic on one
board. Now, with datecode from 2008, we still see this issue. And we see it
on all produced boards, meaing, we should not have shorts or bad soldering
(very unlikly to have the same fault on 5 boards).
Any ideas, what could happen here?
Only I can think of (if that is really a software issue) is that you have
interrupt routine that is not saving the context properly - so that you
select the bank for PORTB, but then an interrupt occurs, so the bank changes
to TRISB and you read that one instead of the port...
On Sun, Nov 9, 2008 at 3:04 PM, jmg <technetz.de> wrote: piclist
I also thought about that.
But context is completly saved when jumping to the interrupt routine. And
this was working with the same firmware on the older production boards.
And I made also a try and, direct before reading the port, I set the bank
properly, but without impact on my issue.
So I do not think, it is caused by software. I think, it is something wrong
inside the PIC, but I do not know what ...
|Consider _all_ the things that have changed...
- did you try a 2006 pic in a new board? (if you have a leftover pic from the past)
- was there a layout change between old and new boards? (error in re-layout or
new layout prone to noise)
- are the new pullups the value you think they are? how about other parts in
that area? (new parts not in spec)
- is the new board located differently in the final assy? (noise introduced)
- is power good all the time? what about brown out issues?
- any other components change, like the brand of motherboard power supply?
(maybe the signal isn't stable)
- are the motherboard and pic grounds tied together and good?
and there may be others. Make a small circuit for test that also samples that
line and is edge triggered, but could drive a buzzer, etc (another pic, a 555,
etc). Put it on the line with your circuit in test and physically see (hear)
when it falsely triggers. It may be only when someone touches something, on a
regular interval, etc, which will give you more ideas on what the source is,
and if the problem goes away when you add to the line, that's important too. It
could even be a pic on a protoboard that also samples the line (or drives an
interrupt), and could measure the time it stays high. Use a different model pic
for that. If it never sees that, and the 877 does, it will get interesting. ;)
I would also verify (compare hex files) that the code hasn't changed since 2006
from a master archived copy. Also write something very simple for the 877 that
doesn't do anything but sample that line and report it. Maybe use a slightly
different, but simple, approach, like a loop. These tests might narrow down a
All that said, this reminds me of a similar mystery 40 yrs ago or so (TTL at
that point). Turns out someone had built a _small_ Van de Graf gen on the other
side of [a very big] building in their space for some testing, and when it ran,
a bit would mysteriously be read wrong over on my side. Of course, it was only
be accident that we discovered it and solved it formally...
> - did you try a 2006 pic in a new board? (if you have a leftover pic
> from the past)
Not yet. I have to take one from the old assembled boards.
> - was there a layout change between old and new boards? (error in re-
> layout or
> new layout prone to noise)
No. No change.
> - are the new pullups the value you think they are? how about other
> parts in
> that area? (new parts not in spec)
Triple checked. Everything ok.
> - is the new board located differently in the final assy? (noise
I used the board in the lab and in the application.
No change in behavior.
> - is power good all the time? what about brown out issues?
Yes, 5V are perfect.
> - any other components change, like the brand of motherboard power
> (maybe the signal isn't stable)
No. Anyway, the problem is not related tot he motherboard and the
I checked also with other brands, and with nothing connected, supply from 5V
lab-PSU. I also connected the Pin 5 direct to GND of the PIC, so noise
should be no issue.
> - are the motherboard and pic grounds tied together and good?
More testing is scheduled during the week.
And I want to write a small test software ...
> All that said, this reminds me of a similar mystery 40 yrs ago or so
> (TTL at
> that point). Turns out someone had built a _small_ Van de Graf gen on
> the other
> side of [a very big] building in their space for some testing, and when
> it ran,
> a bit would mysteriously be read wrong over on my side. Of course, it
> was only
> be accident that we discovered it and solved it formally...
I know that. A long time ago, we made strange measurements in an EMC/EMI
lab. Than we found out, that on the parkingplace on the supermarket 100
meter ago, a gas-discharge lamp was defect, generating giant noise ...
But here, we tested the unit in lab and factory, and they are 500 km away
from eachother ...
Have you checked the cristal? Same brand and model?
On 10 Nov 2008 at 20:52, jmg wrote:
Alan B. Pearce
> So I do not think, it is caused by software. I think, it is something
> inside the PIC, but I do not know what ...
You say the new boards use a 16F877A chip - do the old boards use a 16F877 ?
There are some subtle differences between the two chips.
> You say the new boards use a 16F877A chip - do the old boards
> use a 16F877 ?
> There are some subtle differences between the two chips.
I know, and all are 877A.
More... (looser matching)
- Last day of these posts
- In 2008
, 2009 only
- New search...