Strange pin behavior with pic16f88

Question

I have been learning(trying to at least) how to work with pic microcontrollers, and I have noticed this behavior that I am not sure whether it is just my fault or is supposed to happen. I wrote the below program with hopes to make an led blink. It does blink just fine, when connected to the pin labeled RA2, but when I connect the led to pin 15 (labeled RA6/OSC2/CLKO on datasheet) the led stays on, as though I had connected it to Vdd. Then when I put it back in RA2 where it belongs, it is off. The only way to get it back on again is connecting a 10k resistor between Vdd and MCLR (like how it is when programming). What is happening here? MCLR is also needed when tapping it to some other pins. Am I causing damage?
The circuit is 3 AA batteries powering the pic, with a 330 resistor and 3mm led in series running from pin 1 (RA2) to pin 5 (ground).
pic16f88 datasheet
Code:

#include <xc.h>

__CONFIG(MCLRE_ON & CP_OFF & WDTE_OFF);

void main(){

    TRISA = 0x0000;
   // RB6 = 0b000010;
    for(;;){
        RA2 = 1;
        Wait();
        RA2 = 0;
        Wait();
    }
}
int Wait(void) // gives me a delay of 1/3rd a second or so
{
for (int i = 0; i < 50; i++)
 {
 }
}

Answer 1

You need to tie the MCLR pin high during normal operation otherwise the chip will be held in reset. Notice the bar over MCLR, this means it is active low.
Use a resistor between MCLR and Vdd of around 10kΩ (<40kΩ)
See p.132/133 of datasheet.

Answer 2

Your problem lies on the !MCLR pin. When you program the PIC you are using the VPP function, but the same pin has the !MCLR (Master Clear) function, and since this function is active low, you need to assure this pin stays high so the PIC can run your code. As Oli said, you can achieve this by connecting a pull-up resistor for to the !MCLR pin.

As an alternative you can disable the MCLR function by reseting (writing a 0) the MCLRE bit on the CONFIG1 register.

__CONFIG(MCLRE_OFF & CP_OFF & WDTE_OFF);

Detail of the MCLRE bit from page 130 of the datasheet:

MCLRE: RA5/MCLR/VPP Pin Function Select bit
1 = RA5/MCLR/VPP pin function is MCLR
0 = RA5/MCLR/VPP pin function is digital I/O, MCLR internally tied to VDD

---

Added

Regarding the Read-Modify-Write issue, it happens due to the way the PIC works. 8 bit PICs need four clock cycles for each instruction cycle. Writes are made on the last clock cycle, while reads are made on the first clock cycle. This may cause problems when you are working with different bits of the same port.

Suppose you have the following code:

RA0 = 1;
RA1 = 1;

You would expect that both RA0 and RA1 be high after running this code. This may not be the case. If you have all bits set to 0 on PORTA, when you execute RA0 = 1 the PIC will read the value on PORTA on the first clock cycle, set the bit 0, and write the result back to PORTA. So far no problem, but when you execute the second instruction (RA1 = 1), the PIC will first read the value of PORTA, and most likely the RA0 pin had not time to rise to 1, then the value read for that pin is 0 instead of 1, then the bit 1 is set, then the result is written back to PORTA, but only the bit 1 is set.

To avoid this you can add delays between the instructions like this:

RA0 = 1;
asm("nop");  // No operation
RA1 = 1;

One nop instruction should be enough.

In you code you should not have this problem for two reasons:

1. You are not changing different bits on PORTA
2. You have a wait instruction between writes the bits of PORTA

The shadow register that Leon was talking about consists on a register where the individual bits are modified before writing the whole register to the PORT.

Answer 3

You may want to make sure your config fuses are set such that RA6 is a GPIO pin and not the CLKO function that the pin can also take on. I ran into this problem with a simple program and CCS' compiler. The compiler has such poor documentation that it's impossible to know exactly what is happening without looking at the fuse bits yourself.

I would have expected that whether the LED is on RA2 or RA6, you would have erratic behaviour if MCLR# isn't pulled high. Perhaps RA6 is closer to MCLR# and the problem is exacerbated; not sure.