dspic33fj256mc710 PLL works in reverse!

[AlPicCss73]

Hi Everyone!

It's simple. I've configured my dspic33fj256mc710 to run in higher clocks with external crystal which is 8MHz. But when I use the pll, it just works reversely! I mean, if I use it in 40MIPS mode, it becomes ten times slower. If I use the internal clock everything is fine but by using an external crystal, it's just a mess.
The code is not a big deal:

[RF_Developer]

[AlPicCss73]

Oops! I did a mistake in the text. I'm using an external crystal not an oscillator. Sorry about that. I've corrected it.

[Ttelmah]

Thing is there is no clock figure in the setup.
You need:

#use delay(clock=80000000,crystal=8000000)

internal=xxxx sets the chip up to use the internal oscillator to give the target frequency. It really ought to warn that you have two conflicting settings here, but oscillator checking is an area where CCS never warn (so you can select half a dozen different oscillators at the same time on some chips)...

For a crystal, you need to tell it the crystal frequency, and the target clock frequency, so it can setup the PLL.

[AlPicCss73]

I've tested the

[Ttelmah]

Are you sure your crystal is actually working?.

It'd do what you describe if it wasn't.

Since you have CKFSM enabled, if the crystal wasn't working, it'd fall back to the internal oscillator.
Now if you specify (say) the clock to be 40Mhz, when it drops back to the internal oscillator it'd be running at 1/5th the speed it should (40/7.37). However if you specify 80MHz, it'd then run at 1/10th the speed it should (80/7.37) etc..

So the higher the clock you specify, the slower it'd seem to be running (it'd actually be running at the same speed, but the loop counts used for delays etc., would all be higher, making it look slower)....

What compiler version are you on?.
Reason is that on older compilers you had to explicitly enable the primary oscillator. Just setting the clock statement, did not actually setup the oscillator. So you needed to add the XT, PR_PLL fuses.

Have you got the start-up resistor across the crystal?.
Note under Figure 9-1 in the data sheet (the crystal won't reliably start without this).

Are you aware that this is listed as 'not suitable for new designs'?. You should be using the 33FJ256MC710A.

[AlPicCss73]

I don't understand what's going on!
I knew that it is listed as 'not suitable for new designs', but that was the only choice for me. I've searched the topics and found someone has done it before but it was with an older version of the compiler. I used Ver.5.049 . I'm totally confused.
I never use start-up resistor (and so there was no problem) and in this case the crystal does not work totally not just correctly.

Bests

[Ttelmah]

A lot of crystals will not start at all on this chip without the resistor. This is why the data sheet (for this particular chip), has it as 'required'.....

[AlPicCss73]

I doubt it, but I'll give it a try.

Thanks a lot!

[AlPicCss73]

It was all because a little tiny solder, connected the OSC1 to the vcc directly!

Thanks guys.