View previous topic :: View next topic |
Author |
Message |
Jody
Joined: 08 Sep 2006 Posts: 182
|
PIC18F25K50 A7 as input pin |
Posted: Wed Jan 20, 2021 5:30 pm |
|
|
Hello,
I am using the RA7 as a input pin... and have the fuses set for the internal oscillator.
On that pin there is a 10k pull-up with a normally open switch to ground.
When I debug the program and use the switch (RA7 to ground) my debugger stops and the program doesn't run again.
Looks like a reset.
Checked the power and that is just stable 5V. Checked the RA7 pin and this is going to ground...
Right now I am thinking that I have to tell the controller to use the RA7 pin as a input and that it is not a clock pin or so....
Anyone a idea??
Best regards,
Jody |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9250 Location: Greensville,Ontario
|
|
Posted: Wed Jan 20, 2021 5:54 pm |
|
|
Here's a quick reply for you...
You'll have to read the 'clock' chapter for your PIC but...
From the pic header file.....
Quote: | //////// Fuses: LS24MHZ,LS48MHZ,LP,XT,HSH,HSM,ECH,ECH_IO,RC,RC_IO,INTRC_IO
//////// Fuses: INTRC,ECM,ECM_IO,ECL,ECL_IO,PRIMARY_SW,PRIMARY,NOFCMEN,FCMEN |
INTRC_IO means use the internal RC clock as the 'clock' AND make the I/O pins usually used for the xtal and caps clock available for normal I/O. This gives you 2 extra pins.
INTRC means use the internal RC clock as the 'clock' AND usually makes one I/O pin the clock signal /4.
Jay |
|
|
Jody
Joined: 08 Sep 2006 Posts: 182
|
|
Posted: Thu Jan 21, 2021 3:49 am |
|
|
So just add #FUSES INTRC_IO to the header file will do the trick..
I am going to test it..
thanks in advance!!
I keep you informed!
Best regards,
Jody |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19559
|
|
Posted: Thu Jan 21, 2021 4:28 am |
|
|
Well, yes and no.
You need INTRC_IO, but you need to also remove INTRC if it already
exists, or any other clock fuse.
INTRC_IO 'only', for the clock setting fuses. |
|
|
Jody
Joined: 08 Sep 2006 Posts: 182
|
|
Posted: Sat Jan 23, 2021 4:30 am |
|
|
hello it is not working like I want..
in mine header file:
Code: |
#include <18F25K50.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES INTRC_IO
#use delay(internal = 5MHz)
#define DOOR PIN_A7
|
When I close the door (pull down to GND of pin A7) the debugger stops.
The total program stops......
Did I over look something??
BEst regards,
Jody |
|
|
Jody
Joined: 08 Sep 2006 Posts: 182
|
|
Posted: Sat Jan 23, 2021 4:51 am |
|
|
oke some new info...
When I use the debugger and the door closes the debugger stops.
When I program the uC and let it run the program runs normaly.
Looks like there is something conflicting when using the debugger and this pin..
anybody an Idea???
Best regards,
Jody |
|
|
Jody
Joined: 08 Sep 2006 Posts: 182
|
|
Posted: Sat Jan 23, 2021 5:18 am |
|
|
UPDATE.. again
I have other I/O pin's and it happens to all the I/O pins.
Every pin I pull down my debugger stops working (like there is a breakpoint).
I am starting to pull my hair.... |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9250 Location: Greensville,Ontario
|
|
Posted: Sat Jan 23, 2021 5:50 am |
|
|
hmm this...
Quote: | #use delay(internal = 5MHz) |
Got me thinking, so I grabbed the datasheet.
5 MHz isn't a vaild internal clock speed.
and Yes, the 'debugger' does 'change things' between the PIC and you !
I use MPLAB 8v92 and have never used the 'debugger' option. Prefer to use 'release' mode and test in the Real World.
Jay |
|
|
Jody
Joined: 08 Sep 2006 Posts: 182
|
|
Posted: Sat Jan 23, 2021 6:09 am |
|
|
changed it:
I use: MPLAB8.92
CCS: 5.091
Code: |
#include <18F25K50.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES INTRC_IO
#FUSES NOLVP
#use delay(internal = 8MHz)
#use i2c(Master,Fast,sda=PIN_B0,scl=PIN_B1,force_hw)
|
Release mode in MPLAB you mean??
Jody |
|
|
Jody
Joined: 08 Sep 2006 Posts: 182
|
|
Posted: Sat Jan 23, 2021 6:22 am |
|
|
Oke I have sort of a solution...
Normally when I close the switch pulls the input to ground.
When I not switch it to ground but use a 100 ohm pull down resistor it works.
The pull up on that line is 10k and when I close the door I use 100 ohm to connect to ground.
Some kind of ground debouncing or so??? I didn't see it on the scope but it is possible.
Anybody have a better idea??
regards,
Jody |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9250 Location: Greensville,Ontario
|
|
Posted: Sat Jan 23, 2021 6:22 am |
|
|
While in MPLAB main menu...
click on 'Project'
scroll down to 'Build Configuration'
there are two options...
'release'
'debug'
The default is 'debug' and you need to change to 'release' AND recompile before downloading the code into your PIC. If you set it to 'release' THAT will be the default operation.Previous versions never had the option to store YOUR default as the 'default'.
'Debug' mode adds a lot of 'stuff' to, well, allow you to debug your program.
I ran into this years ago and asked Microchip to allow ME to set what was the 'default' mode as back then, everytime I ran MPLAB, I'd have to change to 'release',recompile,burn the PIC....... The guy on the other end of the phoneline was perplexed when I told him I simply use MPLAB as a 'conduit ' to program in CCS C, then to burn PICs.
Jay |
|
|
gaugeguy
Joined: 05 Apr 2011 Posts: 304
|
|
Posted: Mon Jan 25, 2021 10:27 am |
|
|
It sounds like your "door ground" is at a lower potential than the "processor ground" and the protection diode is getting hit. Always protect I/O that go off board from voltages that may be either too high or too low. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19559
|
|
Posted: Mon Jan 25, 2021 11:18 am |
|
|
Yes.
There is a common behaviour, when pins that have special functions
are taken just outside the supply range (but often before the
protection diode actually works). What happens is that the FET that
forms it's input multiplexor starts to conduct a tiny bit when the voltage
goes outside the supply range. This is why a spike on the MCLR pin
when it is used as an input, can still reset the PIC....
It's a pretty sure sign that the signal is going outside the supply range.
Here it's probably resulting in a spike into the clock circuitry. Generally, it
is a lesson to be very careful with where ground signals actually come
'from', and any signal like this would probably benefit from a small
capacitor on the signal (to reduce signal bounce), and a series resistor
when the signal arrives at the board. Together these help to ensure
that noise and spikes do not do harm. |
|
|
|