Output pin stuck on 2.5 V, will not go high or low

[jlucas]

My project uses a PIC 18F4520 (18F) and a PIC 16F685 (16F). VDD, measured at physical pins 7 and 28 of the 18F and pin 1 of the 16F, is 5.08V. High output from these chips is typically 5.08V, and low output is typically 0.05V.

I have 4 I/O pins on the 18F connected directly to 4 I/O pins on the 16F. There are no other hardware connections to these pins—just simple PCB traces from one pin on one chip to one pin on the other.

One connection is used to send RS-232 data from the 18F to the 16F, which works fine. The other 3 connection are used as flags which simply go high or low to signal between the 2 chips There is 1 output from the 18F, which works fine, and 2 outputs from the 16F, 1 of which works fine, and another which does not work.

The problem connection goes out from pin A4 on the 16F in to pin B1 on the 18F. The voltage, measured at either pin, is 2.46V regardless of whether I send the 16F output high or low. I can toggle it at 1 Hz, and the voltmeter doesn’t even flicker.

If I switch the roles of 2 pairs of pins and use B1 on the 18F as the output and A4 on the 16F as the input, I get a different, albeit still unsatisfactory, result. The low output from the 18F is 0.37V, and the high output is 3.06V which is not being seen as high by the 16F.

If I check the voltages on new boards before I program the chips, these pins always check 5.08V, so apparently it’s not a hardware problem. I’ve checked and rechecked the TRIS, and it’s correct. Also, there are no pull-ups on any of these pins.

Does anyone have any idea what’s going on here? Has anyone seen this before? If so, what can cause this? More importantly, does anyone know how to fix it?

Thanks,

Jim
_________________
Always remember, things are never so bad that they can't get worse.

[FvM]

Show the fuses and setup commands in your code.

[jlucas]

Thanks for getting back to me so quickly. Here's the code:

In the 16F:

[Ttelmah]

I'd suspect the voltage if checked with a scope, is _not_ 2.46v, but a square wave. If you are using a DVM, unless very 'upmarket', these will integrate such a waveform, so you are seeing the _average_ voltage on the pin. Reason, you need the fuse INTRC_IO, not INTRC. Currently pin A4, is connected to the output of the internal oscillator.....

Best Wishes

[RF_Developer]

Is this old code from another compiler?

In CCS you don't need to do set_tris_x() when you are using standard IO, as you are in this code: you don't have any #use fast _io() directives. You think you are setting the IO directions, and you will for a while, but the first output or input will reset them according to the operation. So delete the set tris.

PIN A4 is the clock output pin in many oscillator modes. If you want to use it as a normal IO pin you have to specify an oscillator mode which switches off the normal clock out put on this pin. These modes end in "IO". You specify the clock mode on your 16F685 as INTRC, to be able to use A4 you need to use INTRC_IO.

What's happening is that the 16F685 is outputting its clock on to A4, and that will reads as about half Vdd on a meter, and yes, it won't change when you toggle the output as, of course you are NOT controlling it, the oscillator is regardless of your tris setting. When you turn it around you've got two outputs driving into each other: not a good way to fly. You may have damaged one or both of your PICS, on the otherhand you may have got away with it.

3.06V should be seen as a high by the receiving PIC, but it isn't because its outputting the clock (or trying to) and not acting as an input. You can read it all you like but you won't see anything useful.

Please read the datasheet/s carefully. All this can and should be easily avoided with correct hardware setup.

[Ttelmah]

Fun, isn't it!....
As always, the person who decides to post the 'short form' answer gets in above the one posting a more comprehensive reply. Normally I'm the one who comes in second....

Best Wishes

[FvM]

I don't see it as a competition to answer first. But obviously, the short form answers are exactly hitting the point.

[RF_Developer]

Should I not bother responding then?

[Ttelmah]

I think the key here, is an old one, that should really be 'FAQ' level....

If having a problem on a pin, _always_ start by looking at the pin diagram in the data sheet, and look to see what else might be stopping the pin from doing what you want. Classic things are:
Selection as analog.
A peripheral that is not turned off.
and in this case, you immediately see that this pin is the oscillator output.

Multiple answers often give slightly different views on things, and will sometimes reveal something that one poster didn't think of, which helps everybody to learn.

In a real sense, the 'power' of forum based groups like this.

Best Wishes

[SherpaDoug]

[jlucas]

Thank you all for your very informative and timely responses. You guys are GREAT!

The situation you describe to explain the 2.46V output makes perfect sense -- so much sense, in fact, that I'm not even going to bother dragging out the old O-scope to confirm it!

I'm just going to change INTRC to INTRC_IO, and...

IT WORKS!!!

Okay, it didn't fix EVERY problem I have, but that was the one that's had me high-centered for the past 2 weeks. I'll probably never know why it worked for so long before it went south on me, but at this point, I don't even care. I'm unstuck, and I am EXTREMELY grateful to you all for your help!

I wish you all a Happy Thanksgiving. I'll be giving special thanks to you for your invaluable assistance!
_________________
Always remember, things are never so bad that they can't get worse.

[asmboy]

chiming in on

SET_TRIS_A(0xFB); etc

I confess to NEVER letting the compiler set tris for me dynamically ,
even when i use a port in combo I/O mode.

# use fastio is a dear friend and my default for ALL i/o

much of what i do depends on tight deterministic time domain execution ,
and i find it easier for me to keep track of cpu cycles if i configure it all in advance.

i can agree that somebody who is new to pic programming can benefit from the simplification that compiler auto-tris represents.
perhaps its my assembler roots showing.

[jlucas]

Thanks, asmboy. You guys have all been great. The whole project seems to be falling into place now.
_________________
Always remember, things are never so bad that they can't get worse.

[RF_Developer]

Get that old oscilloscope out and use it. Its way more useful than a DMM when doing embedded (i.e. in our case PIC) development. Its generally the first thing I use, not the last. You could have saved two weeks if you had.

RF Developer

[jlucas]

Good advice, RF.
_________________
Always remember, things are never so bad that they can't get worse.