PIC24 crystal with PLL setup help please [SOLVED]

[benoitstjean]

No, with or without the 1M resistor, no effect on the PLL.

Something so simple yet so mind boggling.

I had it working yesterday until I did something which I have absolutely no idea and from that point on, nothing.

This is what I have which I believe should be correct:

#fuses XT, NOWDT, PR, WPOSTS16, NOCKSNOFSM
#use delay( CRYSTAL=7372800, clock=73728000 )

Still, my pin E7 toggles at 307.3kHz with or without the <clock>. Yesterday, I had it running at 3.073MHz with the <clock>.

Just some minutes ago, while looking at the signal with the oscilloscope, I took fine cutters and cut the contact from the crystal and pin E7 stopped toggling... so the crystal itself is fine and it's definitely not running with the internal oscillator (+ I set the fuse + the code for toggling pin E7 runs therefore the crystal is fine).


I am going back to square one. I desoldered the crystal and will try with a 24MHz just for the sake of it. Looking through my microscope, the pitch on the MCU is so fine that the crystal pins are wider than one pin + the spacing between the pin. That's why I need to solder a little piece of wire-wrap wire so that I can reach the MCU pins without shorting them. I feel like a doctor doing micro-surgery.

Stay tuned.

Ben

[benoitstjean]

Get this... I removed the 7.3MHz crystal, caps and resistor. I now have in place a 24MHz crystal ONLY, without the caps, without the resistor.

With these fuses:

#fuses HS, NOWDT, PR, WPOSTS16, NOCKSNOFSM
#use delay( CRYSTAL=24MHz )

Pin E7 toggles at exactly 1MHz.

If I add <clock=48MHz>, then E7 toggles at 2MHz.

If I change <clock=96MHz>, then E7 toggles at 4MHz.

So PLL kicks-in this time.

The ratio of E7 toggling with frequency is 1:24 hence the 24MHz crystal outputs a 1MHz toggle, 48MHz outputs a 2MHz toggle, 96MHz outputs a 4MHz toggle.

I removed the 24MHz and put back the 7.3728MHz and this time, the PLL doesn't kick-in since I see 307.2KHz.

With the 7.3728MHz crystal, the pin toggles at 307.2KHz (f/24) therefore if the 73.728MHz was working, I'd see 3.072MHz which I am not seeing.

I will place an order right now for crystals in the frequency range I need and do more tests tomorrow.

If you think of anything else, let me know otherwise I will post my findings when I test with new crystals.

Thanks a million.

Ben

[Ttelmah]

The only change I'd make, is to either let the compiler set the fuses or get them right. So:
So:

[benoitstjean]

Ok.... Just placed an order for a few different crystals of various speeds that are a multiple of 7.3728MHz but higher than that frequency (14.7456MHz, 22.1184MHz and 29.4912MHz). The reason is that I have tested two other external crystals that are faster than my stupid 7.3728MHz (16.384MHz and 24MHz) and they both get the PLL working. The only problem is that these frequencies don't work for what I need but at least prove that it's not the code that's broken. Hopefully, what I ordered will do the trick. I will leave this aside until I get the parts.


BUT.... Let's say that for the time until my order arrives tomorrow, I want to test my circuit with the internal oscillator and PLL...

Then what are the fuses and how do I setup the #delay?

I tried this:

#fuses FRC, NOPR, NOWDT, WPOSTS16
#use delay(internal=7.37MHz)

It works because my stuff is displayed on my console but eventually hangs because it's not running fast enough to catch, process and answer all the messages.

So I decided to try this:

#fuses FRC_PLL, NOPR, NOWDT, WPOSTS16
#use delay(internal=7.37MHz, clock=73.7MHz)

That doesn't work. Why? I looked at other posts and don't see anything out of the ordinary.

[Ttelmah]

As I just said. I think your compiler must be old enough to not be correctly setting up the PLL divisors.
I suspect your chip will be running when you select the PLL, but at the wrong rate. Do a basic test with a simple routine that just sits sending data out the serial. I think you are going to find that when you select the PLL, and set the clock rate as you show, the serial rate is wrong (scope the data). The code I pointed to, shows how you can set these yourself.

[benoitstjean]

Compiler is 5.026.

I am home now (not at work). Should get the parts by noon tomorrow so I will update when I test the parts.

Thanks again.

Ben

[Ttelmah]

I suspect you have exactly the same problem that the poster is referring to in the thread I pointed to earlier. He had a chip where when running in PLL mode, the oscillator would not start reliably without a 'kick'.

This would then explain the few occasions where yours has worked (the oscillator did just happen to start correctly).

I have checked with your compiler version, and it is setting the PLL up correctly.

If you look at his fix, what he does is to 'kick' the oscillator pin before starting the PLL.

The code as posted has bits missing (the register definitions). The thread with these is at:

<http://www.ccsinfo.com/forum/viewtopic.php?t=49419&highlight=pllpost0>

You need PLLPRE=0, PLLPOST=0, and PLLFBD=38, to give *10

This takes the incoming clock, and divides it by 2. Then multiplies by 40, then finally divides by 2.

So try his code, substitute these values, and change the frequency in the final clock statement to your 73Mhz figure, and see what happens.

It's interesting, because it suggests it may be 'caused' by perhaps the start characteristics of certain crystals or some particular feature of the board layout, otherwise lots of other people would have experienced it.

[newguy]

My issue was the crystal value. I started with the CCS DSP development kit, which had some variety of dsPIC33FJ-something and a 12MHz crystal. I couldn't get the processor to start reliably, which is what prompted the thread.

The real issue is that, buried very deep in the dsPIC33 family data sheet is that those processors aren't rated to cold start from power-on with PLL enabled if the crystal is above some value. 12MHz was too high. ...That one slipped by CCS when they designed their DSP development kit.

[Ttelmah]

Yes, that was the >8MHz on these. However the similarities are too many to ignore, and it'd be well worth his while to try the code to see if it does start it working. I do wonder about the board layout - possibly something like a ground plane close to the crystal tracks all the way round. The oscillator when running with the PLL, does seem to be much more sensitive to problems than when just running as a crystal.
I don't have a board with his exact chip, but have a couple of others from the same family, and these start every time for me, with the standard settings.

[newguy]

The only time I ever ran into oscillator issues that were my own doing was on one of my first PCBs - I poured a top layer ground plane with a clearance of (from memory) probably 0.010" around the crystal and crystal caps. The increased parasitic capacitance was sufficient to prevent oscillation entirely.

I usually create 4 layer boards now, with layer 2 being a continuous ground plane. I never have oscillator issues anymore.

[benoitstjean]

All right.

So I just realized that most likely I was so wound-up in all this clocking thing for the last few days that I didn't realize that 7.3728MHz is _NOT_ a multiple of what I originally had for oscillator (36.864MHz) SOOOoooo I ordered the wrong crystals! Doh! I should have ordered 9.216MHz and 18.432MHz. My mistake.

[EDIT] Actually, it is a multiple (divide by 5) but doesn't work for the stuff I am trying to do.

BUT.... I guess since the PLL uses a bunch of dividers internally and such, the crystal I put on there is a 29.4912MHz and if I configure the clock like this:

#use delay( crystal = 29491200, clock = 73728000 )

It seems to be working just fine.

The compiler knows how do the PLL calculations to get to 73.728MHz because if I toggle pin E7 hi-lo, as stated yesterday, the pin toggles at a 24:1 ratio. Using the PLL, 73.728MHz / 24 = 3.072MHz and that's what I see on E7 with my scope.

If I remove the <clock> option, then pin E7 toggles at 1.2288MHz which is 1/24 of 29.4912Mhz.

So I guess I can say for now that it's working.

The crystal I am testing is 535-11299-1-ND from DigiKey.

This is my current setup:

#fuses HS, PR, WDT, WPOSTS16
#use delay( crystal = 29491200, clock = 73728000 )

With this crystal, the pk-pk on OSC1 is less than 1V and it is offset by about 1.5V. I didn't even add the 18pf caps yet, nor Rs because it's so tight. Once I re-design that portion of the board, I will add the correct footprints for the resistors (Rs and Rext) so if they are required, I can populate them otherwise I can put a 0 Ohm.

More tests need to be done but it is looking good.

Anymore comments or suggestions are more than welcome otherwise, thanks a million.

Ben

[benoitstjean]

So I've been using crystal 535-11299-1-ND from DigiKey for the last week without any issues.

I guess that the problem really was with that specific 7.3872MHz crystal I had on-hand.

This is my setup:

#fuses HS, PR, WDT, WPOSTS16
#use delay( crystal = 29491200, clock = 73728000 )

With this setup, I can generate a perfect 128kHz 50% duty PWM as well as a whole slew of other PWM frequencies. It also calculates properly (0% error) for 115200/230400 bps UART.

Thanks for all your help, it is very appreciated.

Ben

[Ttelmah]

I was very dubious that your 7.3872MHz, was actually a crystal!....

It's a very common value for crystal filter units used in FM radio IF stages. These look exactly like a crystal, and of course actually contain crystal elements, but produce a different phase shift to a standard resonator crystal.....

Whatever the reason, at least it is working now.