View previous topic :: View next topic |
Author |
Message |
Len152
Joined: 12 Jul 2017 Posts: 4
|
Problem with RA5 on PIC16F18323 |
Posted: Wed Jul 12, 2017 10:12 am |
|
|
Hi,
I am using a PIC16F18323 and cannot get RA5 to work as an input, either digital or analog.
Port A is set up as follows
RA0,1 - used for ICSP
RA2 Analog I/p 0-5V
RA3 MCLR
RA4 Switch Input with a 10K pullup
RA5 Switch Input with a 10K pullup
Port C all outputs
I have tried adding ANSELA command at address 0x18C with the RA5 input set to Digital I/O.
I have checked that the voltage to the pin is correct when I switch it.
Because of the ANSELA possibility I changed the input to an Analog I/p and looked for above halfway and just switching an LED to check it is working. No good.
I tried a different device in case the I/p was damaged - same result
RA4 - No problems with that switched input
Eventually I changed to one of the ports I am not using C1 - worked OK !!!
I now have it working on the C1 port pin but want to know why this is not working on RA5, as this will limit me using this device in future.
Any suggestions?
Thanks |
|
|
alan
Joined: 12 Nov 2012 Posts: 357 Location: South Africa
|
|
Posted: Wed Jul 12, 2017 10:25 am |
|
|
RA5 are also used for the OSC.
Have to set the fuses to enable digital IO.
I think
might work |
|
|
Len152
Joined: 12 Jul 2017 Posts: 4
|
|
Posted: Wed Jul 12, 2017 10:56 am |
|
|
Hi Alan - Just tried it
Did not work. Thanks for the suggestion. I thought you might have had it.
I have now or'ed it with RC1 so I can test it working still on another port pin and check the solutions for RA5 |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Jul 12, 2017 12:30 pm |
|
|
Post a short little program mostly consisting of
1. #include line for your PIC
2. #fuses
3. #use delay() statement
4. A main()
Then we can see what you are doing.
Also post your compiler version. |
|
|
Len152
Joined: 12 Jul 2017 Posts: 4
|
|
Posted: Sun Aug 06, 2017 5:36 am |
|
|
Hi PCM - sorry for the delay in responding. I have been on leave and dealing with a few things.
I am using version 5.051 of the compiler.
Below is the code. I have tried again yesterday with two devices, and was the same. Checked at the device pin for voltage change. Unless I have damaged the two chips in the same way. All work except A5.
Code: |
#include <16F18323.h>
#device ADC=10
#FUSES LVP
#FUSES WDT //Watch Dog Timer
#FUSES RSTOSC_HFINTRC
#FUSES NOCLKOUT
#FUSES BROWNOUT, LPBOR, PUT, BORV27 // Power up Timer and Brownouts
#FUSES PROTECT
#use delay(internal=1000000,restart_wdt)
#use standard_io (ALL)
#define LED_D4 PIN_C4
#define LED_D5 PIN_C3
#define LED_D6 PIN_C5
#define LED_D7 PIN_C2
// #byte ANSELA = 0x18C
void main()
{
setup_wdt(WDT_16S); //~16.3 s reset
setup_oscillator(OSC_HFINTRC_1MHZ);
Set_tris_c (0x02);
port_c_pullups(0x02);
set_tris_a (0xFF);
// ANSELA = 0x04;
setup_adc (ADC_CLOCK_DIV_4);
setup_adc_ports(sAN2,VSS_VDD);
set_adc_channel (2); //RA2
delay_ms (10);
int16 value=0; //A-D Value
Output_low (LED_D4); //reset all LEDs
Output_low (LED_D5);
Output_low (LED_D6);
Output_low (LED_D7);
WHILE (TRUE){
If (!input (PIN_A5)){
Output_high (LED_D5); // grounded pin turns on LED
}
Else {Output_low (LED_D5);}
If (!input (PIN_A4)){
Output_high (LED_D6);
}
Else {Output_low (LED_D6);}
if (!input (PIN_c1)){
Output_high (LED_D7);
}
Else {Output_low (LED_D7);}
set_adc_channel (2);
delay_ms(1);
value = read_adc ();
IF (value > 500){
Output_high (LED_D4);
}
Else {Output_low (LED_D4);}
Delay_ms(100);
}
}
|
|
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9229 Location: Greensville,Ontario
|
|
Posted: Sun Aug 06, 2017 6:58 am |
|
|
OK... stuff to check
1) hardware. use a DMM to 'ringout' ( check_ that pin A5 is not grounded or tied to VDD. There might be a solder 'bridge' or 'whisker' phyiscally causing the problem.
2) software. cut a SIMPLE test A5 program
...
device
basic fuses
main is
forever loop
output_ toggle(pin A5)
delay_ms(500)
forever loop
...
obviously not real code but point is to minimize the program
put an LED- 470R on the pin and/or use scope to see what happens.
it should flash....
also
never set the 'protect' fuse until you're ready for product to leave the door
and
don't bother with the WDT either until 'real code' works properly. You an waste a LOT of time chasing 'what's wrong' when both wdt and code 'collide' !
the simpler it is, the faster you'll fix it.
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19520
|
|
Posted: Sun Aug 06, 2017 7:13 am |
|
|
Several comments:
Are you _sure_ you are using LVP?.
Very few programmers do. If not, then you want the NOLVP fuse.
Then leave the watchdog off in your fuses and enable it only in software.
As it stands, your watchdog is basically pointless. A watchdog should _only_ be reset when the code it working properly. Having reset_wdt instructions scattered through the code, means the code can go badly wrong and still reset the watchdog. Makes it basically pointless....
The point about leaving it off and only setting it up in software, is that if you have any extra boot code (like zero_ram), you may not have time to get to the setup instruction at the start of the code, since the default timing is only 1mSec. So better to leave it off, and only enable it when your code has fully started.
Then get rid of the restart_wdt in your timing declaration, and add a test in your main code, that only calls the restart, if the code is all doing what it should.
Now on your problem. Order. This has come up before. Change your setup to:
Code: |
#include <16F18323.h>
#device ADC=10
#use delay(internal=1000000)
//Move this above the fuses
#FUSES NOLVP //Unless you really are using LVP......
#FUSES WDT_SW //Watch Dog Timer under software control
#FUSES RSTOSC_HFINTRC
#FUSES NOCLKOUT
#FUSES BROWNOUT, LPBOR, PUT, BORV27 // Power up Timer and Brownouts
#FUSES PROTECT
|
The problem is that the clock line, sets up the default internal oscillator _with clock out_. This must therefore be before your fuses, so the fuses can then set the pin for use as normal I/O.
Also, don't enable 'PROTECT' till you have your code working.
With this enabled, every cell in the program memory has to be erased every time you make even a one byte change. Result extra lives are used up while you are developing the code. Protection should only be turned on once code is being sent out to people. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Aug 06, 2017 8:09 am |
|
|
Ttelmah, I don't think that fixes it because it still leaves the ECH fuse set.
I installed vs. 5.051 and compared the .LST file to vs. 5.074.
There are differences, and the important one is that vs. 5.051 enables
the ECH oscillator setting in addition to the 1 MHz internal oscillator.
The ECH setting enables CLKIN on pin RA5. This is the most likely reason
why RA5 doesn't work as an input for you.
Vs. 5.051 (your version). Note that ECH is set in Word 1:
Code: | Configuration Fuses:
Word 1: 2967 ECH RSTOSC_HFINTRC NOCLKOUT CKS FCMEN
Word 2: 38CD MCLR PUT WDT LPBOR BROWNOUT BORV27 PPS1WAY STVREN NODEBUG
Word 3: 2003 NOWRT LVP
Word 4: 0002 PROTECT NOCPD |
Vs. 5.074 (the current version). Now it's set correctly to NOEXTOSC:
Code: | Configuration Fuses:
Word 1: 3FEC NOEXTOSC RSTOSC_HFINTRC NOCLKOUT CKS FCMEN
Word 2: 3DDD MCLR PUT WDT LPBOR BROWNOUT BORV27 PPS1WAY STVREN NODEBUG
Word 3: 3FFF NOWRT LVP
Word 4: 3FFE PROTECT NOCPD |
Adding the NOEXTOSC fuse appears to fix it, as shown below:
Code: | #include <16F18323.h>
#device ADC=10
#FUSES LVP // Should be NOLVP
#FUSES WDT //Watch Dog Timer
#FUSES RSTOSC_HFINTRC
#FUSES NOCLKOUT
#FUSES BROWNOUT, LPBOR, PUT, BORV27 // Power up Timer and Brownouts
#FUSES PROTECT // Should be NOPROTECT
#fuses NOEXTOSC // *** ADD THIS LINE RIGHT HERE ***
#use delay(internal=1000000,restart_wdt)
#use standard_io (ALL) |
It now produces the following Config bits with vs. 5.051:
Code: | Configuration Fuses:
Word 1: 2964 NOEXTOSC RSTOSC_HFINTRC NOCLKOUT CKS FCMEN
Word 2: 38CD MCLR PUT WDT LPBOR BROWNOUT BORV27 PPS1WAY STVREN NODEBUG
Word 3: 2003 NOWRT LVP
Word 4: 0002 PROTECT NOCPD |
|
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19520
|
|
Posted: Sun Aug 06, 2017 10:16 am |
|
|
OK. Fair enough. I tested with the current compiler, not 5.051.
That particular problem with 'ordering' was causing grief only a little while ago for another poster, with the fuse beiing overridden by the CLOCK setting.
That 5.051, is incorrectly enabling the external oscillator when running on the internal was something I did not expect... |
|
|
Len152
Joined: 12 Jul 2017 Posts: 4
|
|
Posted: Tue Aug 22, 2017 9:07 am |
|
|
Thanks guys,
Sorry I did not come back earlier. I have changed the code as you suggested
#fuses NOEXTOSC
and this solves the problem as you said. Looks like they captured it anyway in later versions.
As I said before, I did solve it by using another Pin but good to know why these things happen.
|
|
|
aldina
Joined: 09 Oct 2009 Posts: 26
|
|
Posted: Fri Oct 30, 2020 9:37 am |
|
|
Hello all,
I think I have the same problem with PIC16F18323.
I can not make flash continuously a LED conected on Pin RA5.
Code: |
#include <16F18323.h>
#use delay(internal=1000000)
#FUSES NOLVP
#FUSES NOWDT
#FUSES RSTOSC_HFINTRC
#FUSES NOCLKOUT
#FUSES BROWNOUT, LPBOR, PUT, BORV27
#FUSES NOPROTECT
#FUSES NOEXTOSC
#include <stdio.h>
#include <stdlib.h>
//#use standard_io (ALL)
void main()
{
setup_oscillator(OSC_HFINTRC_1MHZ);
//Set_tris_c (0x00); // 000000
set_tris_a (0x20); // 100000
// Configuration of outputs
output_low(PIN_C3);
while(true)
{
OUTPUT_HIGH(PIN_A5); // flash Port A5
delay_ms(100);
OUTPUT_LOW(PIN_A5);
}
}
| I don't know why, but PIN A5 is always ON (never turn OFF).
Please help me. |
|
|
gaugeguy
Joined: 05 Apr 2011 Posts: 303
|
|
Posted: Fri Oct 30, 2020 10:38 am |
|
|
With the code you have written it does turn off, but it is only off for a few micro seconds and then on for 100 milli seconds. You cannot see that with your eye but an oscilloscope would be able to see it. |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1908
|
|
Posted: Fri Oct 30, 2020 10:40 am |
|
|
You're setting A5 to be an input.
Code: | set_tris_a(0x00); // sets them all to output*** |
*** Note that pin A3 is an input only, per the data sheet.
You're writing 0x20 into port A's tris register. This makes A5 an input. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9229 Location: Greensville,Ontario
|
|
Posted: Mon Nov 02, 2020 9:40 am |
|
|
Unless you've got a lot of 'low level' programming experience, it's best to let the compiler handle the 'tris' setups.
it's way too easy to set the wrong bit, reconfigure a pin, not KNOW that you did it, then spend hours or days trying to see what's gone wrong.
I've only had to use 'fast_io' and 'tris', 2-3 times in 25 years. Each time it was to interface to custom built hardware where timing had to be very, very precise.
Odds are that 99.44% of all PIC projects can /will run fine using 'standard_io', the compiler default. |
|
|
|