PIC16F18325 - Pin voltage shows 2.8V with internal weak pull up enabled and not 5V

Question

I'm trying to configure all pins of PORTA in PIC16F18325 as input pins. I've disabled analog, configured the tristate TRISA register as inputs, setting open drain register - ODCONA to push-pull as well as open drain configuration, and also tried the combinations as mentioned in the data sheet. However, i'm facing a problem that when the pin is configured as an input, it never reaches 5V even when weak pull up enabled.

It always stays at 2.8v. What makes it more worse and confusing is - with the same settings for PORTA and PORTC - some of the pins of both ports - PORTA and PORTC read 2.8V and some read 4.0V.

However, configuring PORTA as output, and toggling the outputs generates 0V and 5V when it changes the state.

Struggling from few days, checked out in microchip forums as well, but no results to find, especially for this chip - PIC16F18325. Any experts who can shed some light / thoughts?

I've also tried using the mcc for code configuration. Disabling brown out reset also. There also same result and no luck.

Below is my complete main.c file.

// PIC16F18325 Configuration Bit Settings
// 'C' source line config statements
// CONFIG1
#pragma config FEXTOSC = OFF    // FEXTOSC 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 = OFF      // Clock Switch Enable bit (The NOSC and NDIV bits cannot be changed by user software)
#pragma config FCMEN = OFF      // Fail-Safe Clock Monitor Enable (Fail-Safe Clock Monitor is disabled)

// CONFIG2
#pragma config MCLRE = ON       // Master Clear Enable bit (MCLR/VPP pin function is MCLR; Weak pull-up enabled)
#pragma config PWRTE = OFF      // Power-up Timer Enable bit (PWRT disabled)
#pragma config WDTE = OFF       // Watchdog Timer Enable bits (WDT disabled; SWDTEN is ignored)
#pragma config LPBOREN = OFF    // Low-power BOR enable bit (ULPBOR disabled)
#pragma config BOREN = OFF      // Brown-out Reset Enable bits (Brown-out Reset disabled)
#pragma config BORV = LOW       // Brown-out Reset Voltage selection bit (Brown-out voltage (Vbor) set to 2.45V)
#pragma config PPS1WAY = OFF    // PPSLOCK bit One-Way Set Enable bit (The PPSLOCK bit can be set and cleared repeatedly (subject to the unlock sequence))
#pragma config STVREN = OFF     // Stack Overflow/Underflow Reset Enable bit (Stack Overflow or Underflow will not cause a Reset)
#pragma config DEBUG = OFF      // Debugger enable bit (Background debugger disabled)

// CONFIG3
#pragma config WRT = OFF        // User NVM self-write protection bits (Write protection off)
#pragma config LVP = OFF        // Low Voltage Programming Enable bit (High Voltage on MCLR/VPP must be used for programming.)

// CONFIG4
#pragma config CP = OFF         // User NVM Program Memory Code Protection bit (User NVM code protection disabled)
#pragma config CPD = OFF        // Data NVM Memory Code Protection bit (Data NVM code protection disabled)

// #pragma config statements should precede project file includes.
// Use project enums instead of #define for ON and OFF.
#define _XTAL_FREQ 4000000
#include <xc.h>
void main(void)
{
    //DISABLE ANALOG INPUTS
    ANSELA = 0x00;
    
    //PORTA PINS ARE INPUTS
    TRISA = 0xFF;
    
    //DISABLE OPEN DRAIN CONTROL ON PORTA
    ODCONA = 0x00;
    
    //ENABLE WEAK PULL UP ON ALL PORTA BITS
    WPUA = 0xFF;
    
    //TRIED BOTH - 0XFF and 0X00; 
    INLVLA = 0x00; 
    
    //DISABLE ALL MULTIPLEXED DEVICES CONNECTED TO PORTA JUST IN CASE THEY ARE CREATING ANY ISSUES
    CM1CON0bits.C1ON = 0; 
    CM2CON0bits.C2ON = 0; 
    DACCON0bits.DAC1EN = 0; 
    SSPCON1bits.SSPEN = 0; 

    while (1)
    {
        // Add your application code
        __delay_ms(100);
    }
}

Any thoughts? TIA

1. It is all of PORTA bits, and not just RA0,RA1.
2. Have tried removing the ICSP header before itself, but did not show any difference. The output of 2.8V is on RA0,RA1 and RA2 pins.
3. I'm using FLUKE multimeter to test the voltage. Other multimeter also shows the same.
4. Configuring the same to PORTC pins have same result. RC1,2,3 have 2.8V, and RC4,5 have 4.0V. When I configure PORTC as output and toggle them, I get 0V and 5V.
5. No devices / nothing connected on any pins of PORTA or PORTC. Just VCC/GND on pins 1 and 8 respectively. MCLR (pin4) is connected to VCC via 10K resistor.

Answer 1

You have left out perhaps the single most important bit of information from your question, that is: What specific pin or pins of PORTA have been measured at 2.8 volts.

If it's just RA0 and RA1 the answer is that you still have the device programmer connected.

The In-Circuit-Serial-Progammers have pull-down resistors on the PGD/PGC lines.

If it's all of PORTA then what do you actually have connected to the port?

Or as GJ suggest are you using a real crap volt meter?

EDIT 1

I looked into the PIC16F18325 data sheet for the pull-up current specification for the weak pull-up function. This is what it shows:

At a minimum pull up current of 25uA the resistance to ground for a 2.8 volt drop is at most 112k ohms.

It's possible that your controller is outside of its specifications.

As a sanity check you may want to measure the input resistance of your volt meter to be certain it is more than 1meg ohm when measuring volts.

EDIT 2

I do not have a PIC16F18325 handy but I do have its bigger cousin the PIC16F18877. The same kind of weak pull-up are implemented in this silicon.

I have tested this controller and all the weak pull-up work as expected.

Suggest that you isolate the PORTA pin that you are measuring 2.8 volts on from your circuit. If you are using the DIP package bend it to just hang out in the air and then measure the pin voltage.

I suggest this because I got all excited that I had replicated you problem but I was wrong. I did my tests using the PICDEM2 plus (DM163022 no longer available) and RA1 behaves just as you described.

It turns out that the latest version (the one I have) connects RA1 to a voltage divider used to sense the battery/DC power input. Removing J12 got RA1 to work correctly with the weak pull-up enabled.