PORTAbits.RA3 read causing the reset

[FrustratedEngineer]

I am using MCLRE pin RA3 as digital i/p. The MCU used is PIC16F15323.

This is the config settings...

// CONFIG1
#pragma config FEXTOSC = OFF    // External Oscillator mode selection bits->Oscillator not enabled
#pragma config RSTOSC = HFINT1    // Power-up default value for COSC bits->HFINTOSC (1MHz)
#pragma config CLKOUTEN = OFF    // Clock Out Enable bit->CLKOUT function is disabled; i/o or oscillator function on OSC2
#pragma config CSWEN = ON    // Clock Switch Enable bit->Writing to NOSC and NDIV is allowed
#pragma config FCMEN = ON    // Fail-Safe Clock Monitor Enable bit->FSCM timer enabled

// CONFIG2
#pragma config MCLRE = OFF    // Master Clear Enable bit->MCLR pin is GPIO -> Dig I/P
#pragma config PWRTE = OFF    // Power-up Timer Enable bit->PWRT disabled
#pragma config LPBOREN = OFF    // Low-Power BOR enable bit->ULPBOR disabled
#pragma config BOREN = ON    // Brown-out reset enable bits->Brown-out Reset Enabled, SBOREN bit is ignored
#pragma config BORV = LO    // Brown-out Reset Voltage Selection->Brown-out Reset Voltage (VBOR) set to 1.9V on LF, and 2.45V on F Devices
#pragma config ZCD = OFF    // Zero-cross detect disable->Zero-cross detect circuit is disabled at POR.
#pragma config PPS1WAY = ON    // Peripheral Pin Select one-way control->The PPSLOCK bit can be cleared and set only once in software
#pragma config STVREN = ON    // Stack Overflow/Underflow Reset Enable bit->Stack Overflow or Underflow will cause a reset

// CONFIG3
#pragma config WDTCPS = WDTCPS_31    // WDT Period Select bits->Divider ratio 1:65536; software control of WDTPS
#pragma config WDTE = ON    // WDT operating mode->WDT enabled regardless of sleep; SWDTEN ignored
#pragma config WDTCWS = WDTCWS_7    // WDT Window Select bits->window always open (100%); software control; keyed access not required
#pragma config WDTCCS = SC    // WDT input clock selector->Software Control

// CONFIG4
#pragma config BBSIZE = BB512    // Boot Block Size Selection bits->512 words boot block size
#pragma config BBEN = OFF    // Boot Block Enable bit->Boot Block disabled
#pragma config SAFEN = OFF    // SAF Enable bit->SAF disabled
#pragma config WRTAPP = OFF    // Application Block Write Protection bit->Application Block not write protected
#pragma config WRTB = OFF    // Boot Block Write Protection bit->Boot Block not write protected
#pragma config WRTC = OFF    // Configuration Register Write Protection bit->Configuration Register not write protected
#pragma config WRTSAF = OFF    // Storage Area Flash Write Protection bit->SAF not write protected
#pragma config LVP = OFF    // Low Voltage Programming Enable bit->Low Voltage programming enabled. MCLR/Vpp pin function is MCLR.

// CONFIG5
#pragma config CP = OFF    // UserNVM Program memory code protection bit->UserNVM code protection disabled

There is switch connected to RA3 pin (a 10K pull up is connected too.) If I press the switch and keep the following code commented, the program works fine.
But, when I uncomment the code and press the switch, the MCU resets.

    if(PORTAbits.RA3 == 1)
    {
        u8KeyPressed = D_KEY_NO_KEY_PRESSED;
    }

The wdt clr function is called and there are no unwanted infinite loops.
Please confirm, where lies the problem.

 

[betwixt]

There is nothing wrong with the code you show or the configuration. I suspect the new value of "u8KeyPressed" causes the problem when you use it. Have you maybe defined "D_KEY_NO_KEY_PRESSED" as a value bigger than u8KeyPressed can hold so it overflows an adjacent variable storage location?

Brian.

 

[FrustratedEngineer]

#define D_KEY_NO_KEY_PRESSED ((U8)0)
 #define D_KEY_PRESSED            ((U8)1)

The macros are defined and associated header file is also included.

 

[betwixt]

I'm not sure which compiler you are using so I'll assume "(U8)" means "unsigned 8-bit char" so that isn't the problem.

My next guess is the port pin is somehow configured as an output and shorting it to ground causes excess current to flow. Please try grounding it through a 1K resistor. That will still pull the logic level down low enough for it to be recognized as low but it will limit the current to a safe level. If it stops the resetting it would suggest the pin is trying to source current rather than sense voltage.

Brian.

 

[andre_luis]

Your above code snipet shows an assignment for the variable u8KeyPressed, but nothing about reading it. Perhaps there are some conditional loop or delay based on the value of this variable.

 

[FrustratedEngineer]

I am using MPLABX IDE with XC8 compiler. U8 - unsigned char typedef'ed

- - - Updated - - -

The pin initialization code...

    /**
    LATx registers
    */   
    LATA = 0x00;    
    LATC = 0x00;    

    /**
    TRISx registers
    */    
    TRISA = 0x20;
    TRISC = 0x00;

    /**
    ANSELx registers
    */   
    ANSELC = 0x00;
    ANSELA = 0x00;

    /**
    WPUx registers
    */ 
    WPUA = 0x00;
    WPUC = 0x00;

    /**
    ODx registers
    */   
    ODCONA = 0x00;
    ODCONC = 0x00;
    
   
    bool state = (unsigned char)GIE;
    GIE = 0;
    PPSLOCK = 0x55;
    PPSLOCK = 0xAA;
    PPSLOCKbits.PPSLOCKED = 0x00; // unlock PPS

    CCP1PPSbits.CCP1PPS = 0x05;   //RA5->CCP1:CCP1;

    PPSLOCK = 0x55;
    PPSLOCK = 0xAA;
    PPSLOCKbits.PPSLOCKED = 0x01; // lock PPS

    GIE = state;

Please make a note, TRISA = 0x28; also had the same result as that of TRISA = 0x20

 

[baileychic]

Try replacing the micro. The micro might be defective.

 

[betwixt]

Look at the actual value in CONFIG4. The data sheet and the comments in your program do not match. If the LVP bit is 'OFF' RA3 should be a digital input but if it is 'ON' the pin becomes the -MCLR input which would result in the symptoms you observe. See data sheet section 5.1

Brian.

 

[andre_luis]

Try replacing the micro. The micro might be defective.

Implausibe supposition, there is no information available enought to substantiate what you said. As mentioned above, if the code is locking in consequence of assigning a specific value to some variable, it would be expected to see posted here part of the code which evaluate this variable. Most of the problems lies in the firmware scope, rather than due to defective MCUs.