dsPIC33 and the upper half of PORTB

Question

I am trying to use some of the IO pins of the dsPIC33FJ128GP802. The pins in question are RB8 thru RB11.

I have written a little program that reads the input value of one of those pins and outputs it to pin RA4.

All I get is straight 0, which ever of those pins I use.

If I use any PORTB pin from 7 down (i.e., the lower byte of the register), it functions perfectly.

I have scraped through the errata, and found nothing that has any bearing on this problem.

What am I missing?

Test program:

#include <p33Fxxxx.h>

_FWDT(FWDTEN_OFF)
_FOSCSEL(FNOSC_PRIPLL)
_FOSC(POSCMD_HS)

int main(void)
{
    unsigned int x=0;
    // Configure clock and PLL for 40 MIPS from 4MHz crystal
    CLKDIVbits.DOZE = 0;
    CLKDIVbits.DOZEN = 0;
    CLKDIVbits.FRCDIV = 0;
    CLKDIVbits.PLLPOST = 0;
    CLKDIVbits.PLLPRE = 0;
    PLLFBDbits.PLLDIV = 78;

    // Disable the CCP output pins as per a bug mentioned in the errata.
    // Should not apply to this case, but just to be sure...
    CMCONbits.C1OUTEN=0;
    CMCONbits.C2OUTEN=0;

    // Disable all ADC pins (make them digital)
    AD1PCFGL = 0xFFFF;

    // Configure IO pins
    TRISBbits.TRISB10=1;    // RB10 Input
    TRISAbits.TRISA4=0;     // RA4 Output

    while(1)
    {
        // Send input state to output pin
        LATAbits.LATA4 = PORTBbits.RB10;
    }
}

Other useful info:

Microchip Language Tool Shell Version v3_30 (Build date: Jun 21 2011).

The inputs are being driven by an Arduino, but using that, or hard-wiring to \$V_{LH}\$ or \$V_{LL}\$ makes no difference.

_{P.S. I am no newbie to PICs, having spent many hours on PIC16s and PIC18s, so don't bother with the "obvious" answers.}

Answer 1

Ok, I have had a response on the Microchip forums...

Apparently the pins associated with the upper half of the PORTB register are shared with the JTAG system. JTAG defaults to on, and can be disabled in the configuration fuses. In MPLAB C30 it is:

_FICD(JTAGEN_OFF)

to disable JTAG.

Once this is done those pins all work perfectly.

Answer 2

• It is not obvious that the PORTB inputs should have a defined state (unless you are driving them high externally and have not told us.

• IF the pins are not externally driven and do not have internal pullups then their state is at the whim of the processors designer and cannot be relied on.

---

I'm unfamiliar with the DSPIC,but it's not obvious why you should be expecting a high level on the inputs unless you are pulling them high externally and have not provided us with that information.

The CNU function allows the programming of internal weak pullups, but these need to be specifically programmed. As your program stands it appears to initialise PORTB as all inputs but does not enable pullups.

If there is not an external high level applied to each input pin and IF it does not have an internal pullup, it will be in an undefined state. In such cases it is not uncommon for behaviour to change at a register or half register boundary - although even if this is consistent it cannot be relied on as the manufacturer may change the behavior at any time without changing the data sheet.

.