It sounds like you have it set up in MPLAB to use the PICkit as a debugger, not a programmer. That will allow it to work with the PICkit connected and running MPLAB, but not stand alone. Make sure the debug config bit is off and that you program the part with the PICkit as a programmer, not as a debugger.
You should check out example 7-2 in the pic24E family reference manual (FRM) titled "Code Example for Using PLL with 7.37 MHz Internal FRC":
// Select Internal FRC at POR
_FOSCSEL(FNOSC_FRC & IESO_OFF);
// Enable Clock Switching and Configure Primary Oscillator in XT mode
_FOSC(FCKSM_CSECMD & OSCIOFNC_OFF & POSCMD_NONE);
int main()
{
// Configure PLL prescaler, PLL postscaler, PLL divisor
PLLFBD=63; // M=65
CLKDIVbits.PLLPOST=0; // N2=2
CLKDIVbits.PLLPRE=0; // N1=2
// Initiate Clock Switch to FRC oscillator with PLL (NOSC=0b001)
__builtin_write_OSCCONH(0x01);
__builtin_write_OSCCONL(OSCCON | 0x01);
// Wait for Clock switch to occur
while (OSCCONbits.COSC!= 0b001);
// Wait for PLL to lock
while (OSCCONbits.LOCK!= 1);
}
It looks like the critical step you're missing is __builtin_write_OSCCONL(OSCCON | 0x01);
Also, looking at the math: 7.37*(76/(2*2)) == 140.03MHz which is slightly outside the allowed range, assuming that 140MHz is actually the maximum range (don't ask me why but for some reason it seems like it may be 120MHz).
If this still doesn't work then perhaps there's just an issue with your power supply. The internal FRC oscillator is unstable under temperature and voltage stress, so perhaps you should check to see if you have too much noise. This would make the FRC wonky as well as the VCO used in the PLL, preventing a lock.
If you look at table 30-18 in the pic24EP128MC206 datasheet, it tells you that over the temperature and voltage range you have about a ±1% for some models and ±2% for others. Figure 31-9 shows the variation with a stable voltage over a temperature range. There doesn't appear to be an analysis of voltage variation at a stable temperature.
If you're trying to get a stable run at a high frequency I would just grab a crystal.
EDIT (from comment):
So from the sounds of your other posts about your conditions it sounds like you should look elsewhere for a problem. What's the frequency of the ripple? Did you size the internal Vreg capacitor properly? It sounds like since this is a locking issue and not a setting issue you're having some other problems with the board that aren't related to your code.
EDIT:
Glad this turned out to be the right answer! Good luck debugging the rest of the board!
Best Answer
As others have said, accurate frequency and frequency stability are reasons to use a external ceramic resonator or crystal. A resonator is several times more accurate than the internal R-C oscillator and good enough for UART communication. A crystal is much more accurate, and necessary if you are doing some other types of communication like CAN, USB, or ethernet.
Another reason for a external crystal is choice of frequency. Crystals come in a wide range of frequencies whereas the internal oscillator is usually one frequency with maybe a choice of 4x PLL enabled. Some newer 24 bit core PICs have both a multiplier and divider in the clock chain so you can hit a wide choice of frequencies from the single internal oscillator frequency.
There are of course various applications that inherently require accurate frequency or timing other than communications. Time is the property in electronics that we can measure most accurately cheaply, so sometimes the problem is transformed into one of measuring time or producing pulses with accurate timing.
Then there are applications which require some long term synchronization with other blocks. A 1% oscillator would be off by over 14 minutes per day if used as the basis for a real time clock. Accurate long term time may also be needed without having to know real time. For example, suppose you want a bunch of low power devices to wake up once every hour to exchange data for a few seconds and then go back to sleep. A 50ppm crystal (very easy to get) will be off no more than 180ms in a hour. A 1% R-C oscillator could be off by 36 seconds though. That would add significant on-time and therefore power requirements to the devices that only needed to communicate for a couple of seconds every hour.