Strange behavior - PORTG.2, 18F8720

I'm using an 18F8720 and needed to use PORTG.2 as an input for the first time. I quickly found that
even though the pin is permanently tied high (to a solid 5V), occassionally, the pin will return
a "0" value when read - but only after a power cycle.

I looked at the datasheet and saw that the pin is also used as Rx in on USART2. I explicity disabled
the USART with the commands TXSTA2 = 0 and RCSTA2 = 0, but that didn't help. I also explicity set
TRISG.2 = 1 in the main program (which loops every 100mSec). That didn't help either. The pin gets read as "0" for
several loops and then magically starts returning "1" again. The problem only occurs after a power cycle -
that is the pin shows a "1" for several seconds after a power cycle, then it returns "0" for several seconds,
then it returns "1" again - forever - or until another power cycle. It acts like an unitialized variable is the problem,
but I can't find any variable that is remotely connected to this issue. I'm ready to write a debug
routine that does a complete register dump whenever it returns a "0", but I won't be able to get to it
until Monday.

When I choose a different pin (on a different port) as an input, all works as expected. I was initially thinking
that this might be a manifestation of a Read/Modify/Write problem (because I DO write to PORTG.1), but
this pin is only used as an input and shouldn't be affected.

This is driving me crazy. Does anyone have any ideas of what could be going wrong?

That's an odd one Charles.

The only thing I could find was in the Errata sheet.
It says it's "Rare", so it's probably not it, but since you say it only happens on power-up, it might be worth a look.

Quote:

---

8. Module: Reset

It has been observed that in certain Reset conditions,
including power-up, the first GOTO instruction
at address 0x0000 may not be executed. This
occurrence is rare and affects very few applications.

To determine if your system is affected, test a
statistically significant number of applications across
the operating temperature, voltage and frequency
ranges of the application. Affected systems will
repeatably fail normal testing. Systems not affected
will continue to not be affected over time.

Work around
Insert a NOP instruction at address 0x0000.

Date Codes that pertain to this issue:
All engineering and production devices.

---

Thanks for responding, Darrel. I'll write some debug code tomorrow to try and figure out what is going on. I already searched through the .lst file and nothing writes to - or changes the direction of that port.