CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Problem with RA5 on PIC16F18323

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Len152



Joined: 12 Jul 2017
Posts: 4

View user's profile Send private message Send e-mail

Problem with RA5 on PIC16F18323
PostPosted: Wed Jul 12, 2017 10:12 am     Reply with quote

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: 349
Location: South Africa

View user's profile Send private message

PostPosted: Wed Jul 12, 2017 10:25 am     Reply with quote

RA5 are also used for the OSC.
Have to set the fuses to enable digital IO.
I think
Code:
#fuses NOCLKOUT

might work
Len152



Joined: 12 Jul 2017
Posts: 4

View user's profile Send private message Send e-mail

PostPosted: Wed Jul 12, 2017 10:56 am     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Jul 12, 2017 12:30 pm     Reply with quote

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

View user's profile Send private message Send e-mail

PostPosted: Sun Aug 06, 2017 5:36 am     Reply with quote

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: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sun Aug 06, 2017 6:58 am     Reply with quote

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: 19195

View user's profile Send private message

PostPosted: Sun Aug 06, 2017 7:13 am     Reply with quote

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

View user's profile Send private message

PostPosted: Sun Aug 06, 2017 8:09 am     Reply with quote

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: 19195

View user's profile Send private message

PostPosted: Sun Aug 06, 2017 10:16 am     Reply with quote

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

View user's profile Send private message Send e-mail

PostPosted: Tue Aug 22, 2017 9:07 am     Reply with quote

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.

Smile
aldina



Joined: 09 Oct 2009
Posts: 26

View user's profile Send private message Send e-mail

PostPosted: Fri Oct 30, 2020 9:37 am     Reply with quote

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: 286

View user's profile Send private message

PostPosted: Fri Oct 30, 2020 10:38 am     Reply with quote

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: 1899

View user's profile Send private message

PostPosted: Fri Oct 30, 2020 10:40 am     Reply with quote

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: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Nov 02, 2020 9:40 am     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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