|
|
View previous topic :: View next topic |
Author |
Message |
jlucas
Joined: 08 May 2011 Posts: 41 Location: Carthage, MO
|
Output pin stuck on 2.5 V, will not go high or low |
Posted: Mon Nov 21, 2011 12:27 am |
|
|
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
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Mon Nov 21, 2011 12:37 am |
|
|
Show the fuses and setup commands in your code. |
|
|
jlucas
Joined: 08 May 2011 Posts: 41 Location: Carthage, MO
|
|
Posted: Mon Nov 21, 2011 1:30 am |
|
|
Thanks for getting back to me so quickly. Here's the code:
In the 16F:
Code: |
#include "16F685.h" // Include Header
#fuses NOWDT,NOPROTECT,BROWNOUT,INTRC,NOPUT
// Watchdog Timer disabled, Code Protect disabled,
// Brown Out Detection enabled, Internal oscillator,
// Power up timer disabled
#use delay(clock=8000000)
#use rs232(baud=9600, rcv=PIN_B7, stream=mc)
void Init()
{
SET_TRIS_A(0xFB);
SET_TRIS_B(0xEF);
SET_TRIS_C(0x00);
output_c(0x00);
port_b_pullups(0x20);
SETUP_ADC_PORTS(NO_ANALOGS);
DISABLE_INTERRUPTS(Global);
output_low(PIN_A4));
output_low(PIN_A2);
output_high(Bicolor1); //LED
}
|
In the 18F:
Code: |
#include "18F4520.h"
#device icd=true
#include "MATH.H"
#reserve 0x007E:0x007F
#reserve 0x00F4:0x00FF
#reserve 0x017E:0x017F
#reserve 0x01F4:0x01FF
#fuses HS,NOPROTECT,BROWNOUT,NOWDT,WDT32768,PUT,NOCPD,STVREN,NOLVP,BORV27,NOWRT,NOIESO
#fuses FCMEN,NOPBADEN,CCP2C1,NOWRTC,NOWRTB,NOEBTR,NOEBTRB,NOCPB,NOLPT1OSC,MCLR,NOXINST
#use delay(clock=20000000)
// Set up RS232 communication with AC4790
#use rs232(baud=57600, xmit=PIN_A5, rcv=PIN_C0, timeout=10, stream=ac)
// Set up RS232 communication with 16F685
#use rs232(baud=9600, xmit=PIN_B0, stream=mc)
void Init()
{
SET_TRIS_A(0xD9); // 1101 1001
SET_TRIS_B(0xFC); // 1111 1100
SET_TRIS_C(0xFF); // 1111 1111
SET_TRIS_D(0xFF); // 1111 1111
SET_TRIS_E(0xFE); // 1111 1110
SETUP_ADC_PORTS(NO_ANALOGS);
output_low(PIN_A1);
output_low(PIN_A2);
output_high(PIN_B0);
output_low(PIN_B2);
output_low(PIN_E0);
return;
}
|
_________________ Always remember, things are never so bad that they can't get worse. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19477
|
|
Posted: Mon Nov 21, 2011 2:58 am |
|
|
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
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Mon Nov 21, 2011 3:11 am |
|
|
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.
Quote: |
...so apparently it’s not a hardware problem. I’ve checked and rechecked the TRIS, and it’s correct.
|
Yes, it is a hardware problem: one related to the way firmware sets up the parts, and your tris are doing b*&&3r all frankly.
There may be other issues of course....
RF Developer
Arrrrg, posting at the same time again |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19477
|
|
Posted: Mon Nov 21, 2011 3:17 am |
|
|
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
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Mon Nov 21, 2011 3:58 am |
|
|
I don't see it as a competition to answer first. But obviously, the short form answers are exactly hitting the point. |
|
|
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Mon Nov 21, 2011 4:45 am |
|
|
Should I not bother responding then? |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19477
|
|
Posted: Mon Nov 21, 2011 4:56 am |
|
|
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
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Mon Nov 21, 2011 7:02 am |
|
|
RF_Developer wrote: | Should I not bother responding then? |
Please do continue. Both replies have merit. Sometimes I only have time to give a quick reply, or a vague one when I don't have access to the compiler or manual. But I at least try to give the person a answer to their immediate problem or an avenue to research on their own. If I have more time I try to give a more educational explanation with maybe some history lesson or programing style points as well. But I don't always have the time. I expect it is the same for many of us. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
jlucas
Joined: 08 May 2011 Posts: 41 Location: Carthage, MO
|
|
Posted: Mon Nov 21, 2011 1:42 pm |
|
|
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
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Mon Nov 21, 2011 5:17 pm |
|
|
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
Joined: 08 May 2011 Posts: 41 Location: Carthage, MO
|
|
Posted: Mon Nov 21, 2011 9:49 pm |
|
|
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
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Tue Nov 22, 2011 2:37 am |
|
|
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
Joined: 08 May 2011 Posts: 41 Location: Carthage, MO
|
|
Posted: Tue Nov 22, 2011 12:01 pm |
|
|
Good advice, RF. _________________ Always remember, things are never so bad that they can't get worse. |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|