PIC24 crystal with PLL setup help please [SOLVED]

[benoitstjean]

Compiler: 5.026
MCU: PIC24EP512GP806

All right, I know this question has probably been answered many places but I guess it'll be quicker to just post the question and get the answer.

These are my settings:

[guy]

Hi! I see no answers yet (the big calibers in the forum went on a weekend? ) and I haven't worked with this chip but I'm going over the errata & data sheet:
There are MANY issues with the chip. Please go over the errata and check it carefully. One important issue is item #9 :

[Ttelmah]

There is no point in using a faster crystal.

The PLL on these chips is not the simple *N PLL of lesser chips.

Instead the incoming clock is _divided_ by a programmable ratio to bring it into the range 0.8 to 8MHz. The PLL can only accept frequencies in this range, so when running off your 36.864MHz oscillator the first thing that will be happening is to divide it down to get inside this range. The divisions supported are 2 to 18. Then this frequency is multiplied by a factor of 2 to 257, to give a frequency that has to be between 120 and 340 MHz. Then the output of this multiplier is divided by a third factor of between 2, and 18 in steps of 2. Phew....

Now your attempt to use 7.37MHz to give 14.74MHz.
If you try all the factors you can't quite get this frequency with the available multipliers and dividers, with the restricted range of frequencies allowed at each stage. You can get very close, but the compiler just tells you it can't do it. The *10, it can manage though, and it ought to be working.

First thing to test is that your crystal actually is oscillating. You say it works, but how do you know?.

If you use just XT, without the PLL (PR), and specify 7.37MHz, for the crystal, what happens?. These oscillators have problems that on many low gain crystals a resistor is needed across the crystal (typically 1.5MR) to get the oscillator to start. On some high gain crystals a series resistor is needed to prevent the oscillator locking onto a harmonic. Are you sure your loading capacitors are the correct value (remember this is not Cl - the capacitors are in parallel with the pin capacitance's and in then in series with each other. ).

As some further comments, in your original version, since you say 'oscillator=', and don't specify a clock fuse, it'll have been selecting EC (external crystal oscillator), not HS ot XT. In your second version, just as in the first, you don't actually have to specify the oscillator fuses. The compiler does it for you. The PLL setup is not actually a fuse option, These chips all boot using their internal oscillator, and then switch on the PLL after boot. This is setup by the clock statement.

As one further comment, you do realise there is nothing special about 7.37 MHz, except that it is the frequency used by the internal oscillator. If using your own crystal, something like 8MHz, is much easier.

[benoitstjean]

Lots of information to digest! As always, thanks for the help!

But.... These nitty gritty details are a bit beyond my knowledge of how all this stuff works internally and although I read and re-read, sometimes I just cannot wrap my head around some topics.

I know the crystal works because I was able somehow to get the MCU to start-up because I use UART2 to display information on a serial console (TeraTerm) and I saw the information go through clearly. I used XT in the fuses so I would guess it was from my crystal. And if I put my scope on the pins (39 or 40, not sure), I see the signal and the frequency is correct.

The reason I am using 7.3728 is because I had it on-hand to test and didn't have the time to order the correct part, whichever that part will be once the clocking and PLL are figured-out.

On my original design, I use a 36.864MHz because this frequency is the closest I can use to 40MHz (max speed of the 24HJ). I am changing my MCU to the 24EP which can go up to 60MHz. However, that exact frequency of 36.864MHz is required because it is used for many other clocks on my circuit (115200 BPS on my UARTs with a calculated 0% error rate, specific sampling frequencies for the attached audio CODEC, precise PWM frequencies out of the PIC etc)....

So I need to have a multiple of that frequency and it just so happens that 7.3728 is 1/5 of that initial oscillator and I happened to have one on-hand out of nowhere (pure luck). So this is perfect for me to test but I will get a faster one later if needed. For now, I'm just testing.

I want to use a crystal rather than an oscillator because the oscillator alone draws 7.5mA.

Really, all I want is to be able to have a clocking signal of at least 36.864MHz just like on my original design, or faster, as long as it is a multiple of that frequency. Trust me, I had to make many calculations to get all the 5-6 different clocking signals I require and that frequency was the only one closest to 40MHz (the one before that was 24.576MHz I think). Frequencies like 32.768 had errors on the UART. Others were OK on the UART but were off on the PWM etc. And others were OK on the UART and PWM but failed to give me the correct clock dividers on my CODEC.... So that frequency or a multiple of that frequency is needed.

And if I use a slower external crystal, then I need to be able to use a PLL internally to increase the frequency.

So.... how do I configure the fuses and is this at all possible (I think the answer is yes, I am just not sure how).

Thanks again, your help is always appreciated.

Ben

[Ttelmah]

You need to start and prove the crystal is working.

The chip will in a lot of modes, by default use CKSFSM, which means it will continue using the internal 7.37MHz oscillator if the external one is not working.

#fuses XT, NOWDT, PR, WPOSTS16, CKSNOFSM
#use delay(CRYSTAL=7.3728MHz )

Then have a simple program just flashing an LED at 1/second intervals, and see if the LED flashes, and at the right rate.

You are probably being 'misled' that the oscillator is working....

With the frequency set for 7.37MHz, your code will apparently run if the oscillator has failed, since this is the frequency of the internal 'fall back' oscillator. With any other frequency setup, it'll run, but everything involving timings (serial etc.), will fail, since the clock will be wrong.

You can test if it has failed by testing 'INT_OSCFAIL':

[benoitstjean]

Hi Ttelmah,

[Ttelmah]

You don't have to add the INT_OSCFAIL interrupt, just test it as I show.
Or turn off the fall back, and _prove_ whether the oscillator is actually working.

The fall back is also to 7.37MHz. If the oscillator was running properly, the signal should be on _both_ oscillator pins. If it is only on one, then there is a problem.

Point is that if the master oscillator was working, then:
#use delay( crystal = 7372800, clock=73728000 ) --> Clock is x10 the crystal speed

would work.

However if the master oscillator is not working, this would result in serial at 1/10th the selected rate (so garbage, unless you were looking for it), as the fail safe will fall back to 7.37MHz from the internal oscillator.

Like Temtronic, I'm a great believer in always having at least one pin that can be used as a LED diagnostic. They are great, since even if you don't fit the LED in production, for basic debugging, they are the simplest and most powerful tool/informative.

Point is, I have tested on your compiler version, and this setup:

[benoitstjean]

Ok for the INT_OSCFAIL but I like the idea that if the oscillator fails, it will generate an interrupt. I can add the code to catch it and I could (I guess) change the clock setting to revert to the default clock and then send myself an SMS from the modem.

Trust me, I am a big proponent of diagnostics options such as LED's and serial ports because they are life savers but this circuit is past the R&D stage. My R&D board was like a christmas tree. This is the production circuit. I am now working on the upgraded version and I am simply going through a list of things that were not implemented on the first rev due to time constraints and the external oscillator was one thing to get rid of.

As for the oscillation of the crystal 7.3728MHz external crystal, I said I tested on one pin (39 or 40) but to be honest, I didn't look on both... only one. My mistake. I just took for granted that it worked on.

I will try this morning all you've explained when I get to work and I will post the results.

Thanks a million. Explanations always thorough and concise.

Benoit

[benoitstjean]

All right. The results are in and I'm confused:

[Ttelmah]

You are never going to get the right rate enabling the PLL, without the clock settings.

You need to understand what I said earlier. The PLL on this chip is _not_ setup by the fuses (except to enable the branch in the oscillator). The PLL is not something you can just 'turn on'.
The chip never wakes up using the PLL. It always wakes using the internal RC oscillator. It then sets up the PLL (which involves writing three separate division factors to the registers for this), then switches to it. Turning it on with the fuses, says to switch to this path after booting, but the registers won't be configured, so you could get almost anything as an output....
The ratio of 'clock' to 'crystal', determines what is put into these dividers.

Now what you are describing, especially talking about a 'wire' to the crystal, suggests you may be hitting a problem of crystal gain and layout.
The PLL circuit is more sensitive than the standard oscillator to the purity of the actual signal. It requires a really clean oscillator running stably at the specified frequency, without significant harmonic or overtone signals present.
You can get the PLL to run at the wrong frequency, by having the oscillator overdriven, and even to lock onto another frequency completely by having other signal traces too close to the oscillator pins, or any significant length in the oscillator traces. The crystal should be as close as possible to the PIC. No more than a very few mm away. Your mention of a 'wire' begins to raise doubts here.
With an external oscillator, the 'clock' input, is just an ordinary logic signal. With a crystal, it is an input to a reasonably high gain amplifier. Needs very different design.

[benoitstjean]

Ok for the PLL fuse, I will remove it.

I know you've explaine lots of things, which I appreciate, the datasheets are also full of info and wrapping my head around all that gets difficult.

Regardless if the fuse is there or not, as much as I thought the code would run, it doesn't appear to be doing anything... EXCEPT if I remove the <clock = 73728000> then it runs fine at 7.3728MHz. So is there a way to know if the PLL has actually kicked-in? I thought I saw a bit in a register somewhere that would tell if the PLL is locked or not.

Given that the code runs if I remove the <clock> option and add the NOCKSNOFSM fuse, I guess it's safe to say that the crystal is fine?

As for the 'wires', I thought also about that... but don't forget, this PCB has tiny components with very fine pitch pins and it's difficult to go in and add things. I have to do this using a microscope. I've soldered wire-wrap wires to pins 39 and 40 as short as possible and used through-hole capacitors (18pf - that's what I had on-hand) to solder from the crystal pins to a close GND pin. I made sure that there is not short between the pins (the code runs with the crystal alone so contacts are fine!).

Also, Figure 9-1 'Oscillator system diagram' page 178 of the DS70616G datasheet for this chip states that:

'If the oscillator is used with XT or HS modes, an external parallel resistor with the value of 1M must be connected'.

So I've added that as well in-between the crysal pins - Not the nicest of the setups but as close as possible to the MCU... and quite frankly, it's cleaner than back in the days when I was doing this on breadboards where contacts were always loose and dirty.

I will be at work shortly so I will go through the steps again and try different things.

Thanks again,

Ben

[newguy]

Maybe take this away from the compiler and do it yourself? I faced a (somewhat) similar issue with a dsPIC33 some time ago which I eventually traced to the PIC not being able to start its oscillator with PLL enabled given the crystal value on the PCB. The compiler version I was using at the time couldn't get it to start reliably given my restrictions. ...So I just "did it myself":

- specify a #use delay statement that causes the processor to start using the internal oscillator
- immediately after cut your own clock switchover code. Might require some special unlock code, probably in assembly

Refer to this thread for ideas: http://www.ccsinfo.com/forum/viewtopic.php?t=47757&highlight=pll+internal

[Ttelmah]

On the oscillator, no. You are missing the critical point about what I'm saying.

You can have a crystal oscillator that apparently runs OK, but get wrong frequencies when you enable the PLL. Commonly when the oscillator is overdriven (crystal gain too high). Pull the sheet 00849a.pdf from Microchip. Look at Figure-9, which is their full recommended circuit for the PIC oscillator. Note Rfext (this is the external resistor you have added - probably not necessary for you it helps the 'start up', and is dependant on the gain of the crystal, and the internal resistances in the particular type of PIC - that your oscillator starts every time, suggests that you have a high gain crystal). Then notice Rs. This is essential if the crystal is high gain. It is what stops the oscillator input from being overdriven. Now if the oscillator is overdriven, it'll apparently run OK, but will prevent the PLL from locking onto the correct frequency....

Read the paragraph after the diagram "Examining the Oscillator Output Signal". You ideally want a smooth sinusoid just getting close to the supply rails. If there is clipping, then the PLL can lock onto the wrong frequency.

Typically Rs values around perhaps 2KR are enough to stop the PLL from having this problem, but they describe using values much higher

[benoitstjean]

All right.... Reading the suggested datasheet <http://www.t-es-t.hu/download/microchip/an849a.pdf> and looking at Figure 9 then under the <Examining the Oscillator Output Signal> section, it states:

"On an oscilloscope the Osc-Out signal should be a nice clean sine wave that easily spans the input minimum of the clock-input pin (as much as 4V peak-to-peak for a 5V VDD)". I guess that by Osc-Out, they mean pin 40 (OSC2)?

I added the 2K series resistor 'Rs' between the crystal and OSC 2 and disconnected the 1M parralel resistor (as per your indication that it was most likely not required, regardless, it does not seem to change the behaviour if it's there or not).

My oscilloscope is set to 1V/div. My circuit is running at 3.52V.

For pin 39 - OSC 1 (directly to Xtal and C1): A 7.3MHz signal of about 216mV pk-pk biased at around 1.52V.

For Pin 40 - OSC 2 (with Rs = 2K), my measurements seem to coincide with the explanation: A 7.3MHz signal biased at around 1.5V with a pk-pk of around 2.8v (voltage swings between approximately 566mV-2.88V). Frequency does not drift or anything. It seems pretty stable. It is a nice sinewave, no glitches, no clipping, nothing special.

Then on the crystal directly on the other side of Rs coming from pin 40, the amplitude is attenuated and very low, I'd say the pk-pk voltage is around 400mV and 7.3MHz.

Does this seem correct?


Ben

[Ttelmah]

Yes. Sounds good.

You'll see that the Rfext, they here say is likely to only be needed by ceramic resonators with a lower gain.

Does it make any difference?.