MCF52221 PLL question

[RobNijhuis]

Hi,

We are clocking the MCF52221 from it’s internal relaxation oscillator, PLL'd up to 48MHz. We have found out that the relaxation oscillator runs too fast  for USB to work correctly. We have found out that the relaxation oscillator has a tolerance of 32,500 ppm. In case we place an external oscillator, the problem is solved. We don’t like to do a hardware redesign of our product. So the question is how to solve this problem (in software). Is this possible ?

We played with the ROCR register to use the trim bits to changes the frequency, however no mather the value we write we don't see a change. We use the following code to setup the PLL

 // set PLL to 6x, so system clock is set to 8MHz osc * 6 = 48 MHz, needed for USB.
 MCF_CLOCK_CCHR = 0x00;
 MCF_CLOCK_SYNCR = MCF_CLOCK_SYNCR_MFD(1) | MCF_CLOCK_SYNCR_RFD(0) | MCF_CLOCK_SYNCR_PLLMODE | MCF_CLOCK_SYNCR_PLLEN;
    // wait for pll to lock
    while (!(MCF_CLOCK_SYNSR & MCF_CLOCK_SYNSR_LOCK))
     ;
    // switch over from reference clock to PLL output
    MCF_CLOCK_SYNCR = MCF_CLOCK_SYNCR_MFD(1) | MCF_CLOCK_SYNCR_RFD(0) | MCF_CLOCK_SYNCR_PLLMODE |
     MCF_CLOCK_SYNCR_PLLEN | MCF_CLOCK_SYNCR_CLKSRC;

If anyone has any ideas...please let me know.

Thanks,

Rob

[RichTestardi]

I'll add one observation to Rob's initial post...

The documentation on ROCR says:

> 2 The reset value for ROCR is loaded during reset from the flash information row

> (bits [9:0]). The bits reset to 0b10_0000_0000 during Power-On Reset.

And other documentation from Freescale (for other processors) has this footnote for the "flash information row":

> IFR — Nonvolatile information memory that can only be accessed during production

> test. During production test, system initialization, configuration, and test information

> is stored in the IFR. This information cannot be read or modified in normal user or

> background debug modes.

So it is possible the ROCR can't be changed by the user (which seems to be indicated by the register being read-only in the 5222x documentation -- all the "W" positions are greyed out).

[RobNijhuis]

Hi all,

Thanks for your input, we actually intend to use a 8Mhz x-tal and multiply it to 48 Mhz because obviously using the internal relaxation filter doesn't work. We checked this configuration, out Techtronics scope says that we're inside USB specification.

I'll check the remark regarding the 48Mhz x-tal.

Rob

[RichTestardi]

Hi Rob,

I'm very interested in what you conclude here because I am in the same position, using the internal relaxation oscillator PLL'd up to 48MHz and running USB (I am in device mode -- are you in host or device mode?).

The USB Full Speed Spec really demands you use a crystal, at 2500 ppm, but my experience with the M52221DEMO board (both mine work fine with the relaxation oscillator) led me to take a chance otherwise.

So far I have assembled just under 20 boards (by hand) and what I have noticed is that immediately following assembly they *never* work with USB (everything else works and I can load code and run it).

The strange thing is, following *cleaning*, every single board works on USB (on multiple computers).  It is perplexing to me that cleaning should have such an effect.

What percentage of your boards work?

My board is *very* simple and adding a crystal will not only increase cost by 10%, it will increase board size...  I'm considering laying out for the crystal and depopulating it by default, but have not done so yet.

As far as the accuracy of the relaxation oscillator is concerned, my parts run from 8.01 to 9.43 MHz as measured from PSTCLK (which is more than the +/-20,000 ppm I expected), and all of them are fine on USB (device mode).

My startup code is below.

-- Rich

Code:

    // we use the 8MHz internal oscillator    MCF_CLOCK_CCHR = 0;    // and multiply by 6 to get 48MHz    MCF_CLOCK_SYNCR = MCF_CLOCK_SYNCR_MFD(1)|MCF_CLOCK_SYNCR_CLKSRC|MCF_CLOCK_SYNCR_PLLMODE|MCF_CLOCK_SYNCR_PLLEN;    while (!(MCF_CLOCK_SYNSR & MCF_CLOCK_SYNSR_LOCK)) {        // NULL    }

 

[RichTestardi]

Doh, and please ignore my PSTCLK numbers!  My (inexpensive, digital) scope was aliasing at too low a sample rate!  So that exaggerated the difference...  For real-time execution, my boards show a 0-5% difference in clock speed.  Sorry.

[mjbcswitzerland]

Hi Rich

Freescale intends for the USB clock to be derived directly from the 48 MHz crystal or from the USB_ALTCLK bypass input (reference John Bodnar, Systems Engineer, Freescale Semiconductor, Inc. - see Wildrice archives (www.wildrice.com).

The reason is not just the accuracy of the clock but also the PLL jitter. Running any clock source other than 48MHz crystal, multiplied up to the USB frequency, results in jitter outside of the USB full speed specification. This may still work but obviously isn't guarantied. For anything more that experimental use I think that a 48MHz will need to be used, however much it hurts to put it in...

Unfortunately I (also) don't have any experience with trimming the relaxation oscillator. This could be useful to get the USB operational in a study environment (such as student learning boards) but I am not convinced of its real use in the M5221x/2x since I wouldn't expect anyone to use it in an application without USB (I mean that is what they are really for) and any commercial product will use a 48MHz souce since anything else is neglegence (based on the known information).

Regards

Mark

www.uTasker.com

[RichTestardi]

> such as student learning boards...

Which, of course, is exactly what I am building! :smileyhappy:

[mjbcswitzerland]

Rich

Insider knowledge... that is why I mentioned it...!!

Regards

Mark