MCF54415 external oscillator requirements

[mwood]

I would like to use a specific TCXO with the the MCF54415 that has a clipped sinewave output. Will this work or do i need to use a oscillator with CMOS output? I haven't been able to find any documentation or requirements for the oscillator input.

[TomE]

It is all there in the Reference Manual, but you probably need a bit of experience with previous chips to really "get" what they're on about.

Read up about the "OSCMODE" bit in "9.3.1 Chip Configuration Register (CCR)". To use an oscillator you have to set that bit *BEFORE* the chip comes out of reset. Tricky...

That gets set by using one of the "Override" modes defined in "9.2.1 BOOTMOD[1:0]".

Instead of having a whole lot of pins dedicated to the power-on configuration (this chip would need 6 or more pins for this), many ColdFire chips have a "Default Mode" which is the common way to use it, and the "Override" mode. If you want anything other than the "default" (and using an external crystal is the default and using an oscillator isn't) then you connect BOOTMOD up the other way, which turns FB_A[21:17] into "hardware configuration pins" during Reset. You have to "actively drive" these pins during Reset.

Which means you have to change your hardware. If you look at the Reference Designs, they have these connections for people who need to use a "non-default mode".

The Reference Manuals all say "Actively Drive", which means connecting a tri-state driver to these pins, enabled by one of the Reset sgnals. When you look at the Reference Designs to see how to do this properly, you'll usually find most of those designs use pullup and pulldown resistors in violation of the Reference Manual! We've been here before:

https://community.freescale.com/message/85646#85646

Tom

[mwood]

Thanks Tom, this is all good information and I'll look into it further. However my question is about the "type" of oscillator being used. I probably wasn't clear in my original question. Many oscillators come in two, or more, flavors for the output. Two of the more common are 1) CMOS and 2) clipped sinewave. My understanding is that the clipped sinewave type doesn't oscillate between logic levels but provides a signal that is approx. 1V peak-to-peak.

My question relates to the difference between these two options and whether the clipped sinewave will work with the processor. I know that the CMOS type output will work fine but I haven't been able to find one that also meets my requirements for things like phase noise, allan deviation, stability, package size, etc. However I have found such an animal with a clipped sinewave output.

Unfortunately, this will be a modification to an existing product, just swapping parts, so the oscillator must fit the existing footprint on the board and I can't add any additional buffer between the osc and processor. This limits my options.

[TomE]

You originally said:

> I haven't been able to find any documentation or requirements for the oscillator input.

Sorry, I wrongly assumed you were one of the posters here who can't read a Data Sheet, as the oscillator input is documented there :-).

> whether the clipped sinewave will work with the processor.

The voltage levels for the EXTAL pin are given in the Data Sheet in "4.8 Oscillator and PLL electrical characteristics" as EVih and EVil which are 0.35 and 0.65 EVdd, or from 1.16 to 2.15, or a swing of 0.99V. That's very close to "approx. 1V peak-to-peak", but with no design margin at all and an impossibly tight requirement on the thresholds. The oscillator might give guarantees on the levels that can be made to better these levels.

The Data Sheet doesn't give minimum slew rates on inputs. It would be nice if it did.

If that doesn't work, the EXTAL input might be more sensitive (to lower swings) when in Crystal mode. That assumes we can believe "Figure 8-1. Device Clock Connections". So you might be able to change the BOOTMOD pins to use the oscillator as the buffer - as long as the existing design gives you strapping options on BOOTMOD and you can work in Default Mode. Murphy says you won't be that lucky. This is also operating outside of published specifications, so you'd have to reverse-engineer the part's characteristics and write your own tests and specs.

Getting the "clipped sine wave" to meet the 45%/55% duty cycle requirement might be tricky.

> the oscillator must fit the existing footprint on the board

Maybe you can do it the old fashioned way if the budget will stretch. Make a small adapter board with the crystal and a buffer on it that mounts on the existing footprint.

> phase noise, allan deviation, stability

Good. Someone treating a crystal with the respect it deserves (as compared to the way most people treat these complicated and magical little components :-). I trust you're familiar with John R Vig's documents on the subject:

http://www.ieee-uffc.org/frequency_control/teaching/pdf/fcdevices.pdf

http://www.am1.us/Local_Papers/U11625 VIG-TUTORIAL.pdf

For the benefit of others who might like to read up on how complicated a crystal can be, follow the references (especially #45 which points to the above documents) from:

http://en.wikipedia.org/wiki/Crystal_oscillator

I'm interested in  what you need the stability for. There don't seem to be any internal peripherals that can make use of a high stability. I assume you're sampling a precision time source (or trying to be one). The PITs, DMA Timers and PWMs all run from the PLL and not from the crystal, so is the PLL likely to add to any oscillator noise problems in your application?

If you're timing anything using the PITs, watch out for the "Bear PIT" that can give you a 24% timer error:

Re: PIT hw boo-boo. Read if you need accurate PIT (CF)

Tom

[mwood]

Tom,

OK, I'm starting to feel stupid, I totally missed the EVih and EVil specs. It's clear that clipped sine wave type is not suitable without some extra surgery. I'll keep looking for a part that requires less intervention and keep the sine wave option as a fall back position. I'm sure I haven't seen everything available so maybe the perfect part is just around the corner.

Using the crystal mode would create some other issues for me. The oscillator modification is to be made to an OEM module and the manufacturer has agreed to a part swap for a certain volume at no additional cost. There would be NRE fees involved if it required hardware modifications. I'm just trying to avoid that. I haven't asked about how much the NRE would be since I don't know what changes are to be made yet. But in the end I guess that for the quantities being discussed the NRE would be a small price to pay when averaged over the quantity. I'm getting off topic but maybe that will give you a little context.

The basic function of the system is to timestamp events or more precisely measure the time between events and the system is composed of multiple modules that are connected over a Wifi link. Not only does the timing accuracy on a module need to be accurate but the modules need to be time synchronized between each other. It sounds like an impossible task but I have a working system that cost's more than I care to elaborate on. My goal for this task is to build a system that is greatly less expensive than the existing one and a little loss in performance is OK.

The critical part of the processor that I'm relying on is the capture capability of the DMA timers. The DMA timers can timestamp events at about 8ns resolution assuming a stable clock. The clock drift between modules is handled in software and communication over the Wifi link. The system requires quite a bit of software for calibration, drift corrections, etc. but luckily I already have that from the other system. The timestamp from the DMA timers provides a coarse measure and with some external circuitry the events are interpolated down to about 1ns resolution.

However, the point you make about the PLL may kill my perfectly laid plans. I had been assuming that the jitter was some small fraction of the clock period but the spec sheet gives the PLL jitter as 10% percent of fsys/3. Usually jitter is expressed in time. I'm not sure what to think about this. Does it mean 0.1 / (250e6/3) =>  1.2ns? If so I may still be OK.

Mark

[TomE]

> I totally missed the EVih and EVil specs.

Well they're half "evil", so best missed...

Watch out for the problems with the latest version of the manual. You may need to get the V3 manual if you're doing anything with eDMA. There are also problems with the DMA Timer documentation. Read this:

MCF54415 eDMA help

I said:

>> The Data Sheet doesn't give minimum slew rates on inputs. It would be nice if it did.

The MCF54455 Data Sheet does give this information. It requires a 20% to 80% slew in 2ns. It is a different design, but this might be useful as a ballpark figure.

> modules need to be time synchronized between each other.

We do the same over CAN buses. Some CAN chips have hardware timestamps, other ones don't. For them we rely on the interrupts to capture the time.

The "existing technology" is for time synchronisation is:

Precision Time Protocol - Wikipedia, the free encyclopedia

http://www.freescale.com/webapp/sps/site/application.jsp?code=APLIEEE_1588

That can benefit from, but doesn't require IEEE 1588 support in the chip itself. The MCF5329, MCF5329, MCF5208 and MCF5441x have this but many don't, so you've got the right chip. Delays introduced by WiFi would be another complicating factor.

> PLL jitter

From the diagram, the PLL looks to be a single-stage divider and comparator. It isn't one of these that can divide both the input and the output and then compare the result of that. Those ones can drift by the final divided result. This one shouldn't be able to drift more than a fraction of the input clock period, which is 14 - 50MHz.

Extra care around the PLL power filtering (VDD_OSC_A_PLL and VSS_OSC_A_PLL) might help, but as it is an OEM unit you don't have control of this. It would be worth checking their design and layout to make sure this isn't a problem. And if you can find a coil with an inductance of "100MHz", I'd like to see it (Data Sheet - Figure 1. Oscillator/PLL/DAC power filter).

Tom

[mwood]

The MCF54415 eDMA help link you reference was one I started awhile back. FYI, I got past all the DMA stuff and that part is working beautifully. Originally I wasn't sure if I could detect the pulse edges close enough using this technique but everything worked out. I had first tried using interrupts but that was too slow. The pulses can be as close as 500ns apart. Testing has shown that using the DMA I can get down to about 225ns between pulses before I start missing detects.

I had looked into the 1588 PTP before on the original system and it didn't look like it was going to be accurate enough so we took another route. Requirements have changed though for this inexpensive version so it's probably worth revisiting. BTW, I had looked at the precision PHYTER chip from National, now TI, that has hardware support for 1588 PTP. They report < 1ns synchronization time for wired network. If I do a full custom solution for a wired network in the future this may be the way to go. http://www.ti.com/lit/an/snla100/snla100.pdf

I looked all around for that 100MHz inductor, it's nowhere to be found. But seriously, thanks for your input, it's been very helpful.

Mark