PIC18F2525 Port C pins made output causes problems in other circuits

I have been grabbing for straws for about 20 hours on this. I have two 18F2525s working together and using 4 lines of DIO to do signal a few different states between the two. The issue I have boils down to this: One 2525 has PortC.0-PortC.3 each going directly to the gate of a NIF5003NT1G. The other 2525 runs several devices through SEROUT2/SERIN2. The problem I am running into is that when the code gets to the point of setting the TRISC registers for those four pins to "0" it disrupts the LCD screen the other PIC is running. I am guessing I am missing some configuration bit and the pins are creating noise on the PCB when they are configured as an output. Can anybody look at this quickly and tell me if they see something obvious? I don't want to post all the code for both PICs as well as the PCB layout because if the problem is that deep then it is beyond the scope of the help I should be seeking on this forum and I should just be hiring somebody to do this for me. Thanks in advance.


osccon = %10000010 'this changes to internal 32khz

#CONFIG
CONFIG IESO = OFF
CONFIG OSC = INTIO67
CONFIG PWRT = ON
CONFIG BOREN = SBORDIS
CONFIG BORV = 3
CONFIG WDT = OFF
CONFIG WDTPS = 2048
CONFIG CCP2MX = PORTC
CONFIG PBADEN = OFF
CONFIG LPT1OSC = OFF
CONFIG MCLRE = OFF
CONFIG STVREN = ON
CONFIG LVP = OFF
CONFIG XINST = OFF
CONFIG DEBUG = OFF

#ENDCONFIG


CMCON = 7
ADCON1 = %00001111
CCP1CON = %00000000
T1CON = %00000100
T3CON = %00000100
SSPCON1 = %00000101

LOW PORTC.6

PAUSEUS 50

Port1MOS var portc.0
Port2MOS var portc.1
Port3MOS var portc.2
Port4MOS var portc.3

Port1sense var porta.0
Port2sense var porta.1
Port3sense var porta.2
Port4sense var porta.3

trisa.5 = 1

trisc.0 = 0
trisc.1 = 0
trisc.2 = 0
trisc.3 = 0

trisa.0 = 1
trisa.1 = 1
trisa.2 = 1
trisa.3 = 1

'DEFINE OSC 40
'do
'loop



do
if port1sense = 0 or port2sense = 0 or port3sense = 0 or port4sense = 0 then
high portc.6 'goes to b.3 on master
pause 1
endif
if port1sense = 1 and port2sense = 1 and port3sense = 1 and port4sense = 1 then
low portc.6
pause 1
endif

if porta.5 = 1 then 'goes to a.5 on master
high portc.0
high portc.1
high portc.2
high portc.3

endif

if porta.5 = 0 then

low portc.0
low portc.1
low portc.2
low portc.3
endif

loop

The code driving the LCD is the one that we should be looking at. This is the "other" PIC right?

In the meantime, look at the PORT sections in the datasheet, specifically for <multiplexing>. PICs often share pins between devices, I'd bet you have a feature enabled that is disturbing the LCD pins. Or a config doing more than you expect.

Robert

The other PIC does run the LCD but displays everything just fine until this PIC is plugged in. It also displays fine if plug the PIC in but comment out the setting of the TRIS registers for those four pins. I have been through the datasheet 100 times already and can find nothing. I even did the obligatory change everything for the sake of doing it just to see if I can trial and error my way to a solution. This includes the muiltiplex settings. There is one specifically that affects those pins but changing the multiplex settings doesn't change anything that I can see. I was just hoping somebody has had a similar experience and can show me some comment or misprint in the datasheet that I missed and would lead me to the promised land. As I said in my initial post, there are a lot of great people on this forum that would dedicate hours of their own time to helping me find the problem but I don't feel right asking for that because by the time somebody figured out all my "not commented" code and looked at my PCB layout (I didn't do a schematic, I just went straight to the layout) they would be hours into it. Thanks again.

It would have been quicker to post your code of the pic driving the lcd.

I just found the issue. It is a mystery why this PIC was affecting the LCD but it appears the display is very sensitive to BOR. If the ground is switched off and back on within 15 seconds or so the LCD just displays gibberish. Past that, it is fine. Putting a 470 ohm resistor across the power and ground fixes the issue entirely. I am not sure why the presence or absence of a PIC with only the power circuit common would affect that but it does. Thanks for the suggestions.

Don't you mean capacitor instead of resistor? I would expect a small 470 ohm resistor across power and ground would do something funky, like magic smoke.

On the PIC driving the LCD, do you have a short PAUSE to give time for the LCD to initialize?

Also, when you connect the other PIC, does that also include connecting other devices that consume more current than PICs, LEDs and other low-consumption devices, possibly a motor, stepper, solenoid, etc?

Adding a capacitor would stabilize the voltage on the circuit. Most circuits have capacitors right after the incoming power connection. It would seem as if you are adding a considerable load along with the other PIC, the voltage drops momentarily and the LCD doesn't like it.

Of course this is all guesswork from a novice without any schematic or code.

Robert

I just typed for 15 minutes explaining everything and pressed "Reply to Thread" instead of the button on the bottom "Post Quick Reply" which wiped out everything I typed. This might be something that could be fixed on the forum because I am sure I am not the only one and after this week, the last thing I needed was that.

At 5v the 470 ohm draws a little less than 11 mA and less than 1/16 of a watt. No smoke and I wouldn't expect any.

There are pauses to account for the LCD and I tried several different baud rates.

Power consumption is not an issue. During regular operation everything draws 10% of the regulator's maximum capacity.

During troubleshooting I went from cutting all the capacitors out to giving the ones normally in place other capacitors to hang out with so they wouldn't be lonely. None of it made a difference. Normally there are capacitors on both the supplied and supply side of all regulators as is the case here.

The resistor is the only thing that has worked. It was done on a hunch based on "time" fixing the problem and an assumption that there was some stored charge somewhere causing the issue. I don't know exactly why it works but for now it does and that is what I needed.

Try running the system from batteries and see what happens. I had a similar problem once and it was fixed by building a really good power supply.

The system does run on batteries. That doesn't mean there aren't other sources of noise on the board but during troubleshooting I reduced or removed all of them to the maximum extent possible. I still think that has something to do with it but it is beyond my understanding and despite my curiosity in finding the cut and dry reason for everything, I just don't have time right now. It might be a retirement project of mine.