Crystal starting problem
Dave VanHorn
Peter Liew wrote in message <5cRO2.110$wc7....@news.clear.net.nz>...
>Hi fellas,
>I'm experiencing some difficulties in starting a crystal up. This
crystal
>is driven by a PIC and when reseting from standby often the crystal
refuse
>to start, but if I touch the crystal with my finger it will start.
Why is it always the PIC guys with the crystal problems...
Oh well.
Bypass caps on the uP supply?
Proper value of loading cap on the crystal? (not from someone's
circuit, it's in the xtal's spec sheet)
Pic programmed to right oscillator mode?
Paralell resonant fundamental mode xtal?
Xtal caps going straight to Pic's ground pin?
Todd K. Moyer
capacitance you put on the board. So you may have to go several pF lower on
the cap values than you would otherwise expect. The fact that lowering the
capacitance "improves it slightly" may be telling you something. I'm just
giving you a justification to go even lower. Another engineer at my last job
had this problem, and he had to go lower on the capacitors than he first
expected.
By the way, you do have the crystal fairly close to the uP, right?
Todd
Dave VanHorn wrote in message <7KRO2.7712$033....@news.rdc1.il.home.com>...
Peter Liew
I'm experiencing some difficulties in starting a crystal up. This crystal
is driven by a PIC and when reseting from standby often the crystal refuse
to start, but if I touch the crystal with my finger it will start.
I've tried reducing the capacitive loading on the crystal which improves it
slightly but does not eliminate the problem.
Has anyone experienced this problem before? What solutions could you
suggest for me to try?
Thanks in advance.
Peter.
Tap
Make sure your using the correct type (XT,HS)
Use 10-40 pf caps on both pins of Xtal and ground
Tap
Tap
wrote:
>Why is it always the PIC guys with the crystal problems...
>Oh well.
I think its because a PIC is the first time most newbies have ever
hooked up a Xtal to anything, and the other reasons are in your reply
Dave VanHorn
>>Why is it always the PIC guys with the crystal problems...
>
>>Oh well.
>I think its because a PIC is the first time most newbies have ever
>hooked up a Xtal to anything, and the other reasons are in your reply
On a 6502 based system, we had some trouble with the crystals
STOPPING, due to nearby ESD events.
Board layout fixed it. I've never had trouble with a rock on any box
other than that though.
douglas dwyer
<dvan...@cedar.net> writes
>On a 6502 based system, we had some trouble with the crystals
>STOPPING, due to nearby ESD events.
>Board layout fixed it. I've never had trouble with a rock on any box
>other than that though.
surface becomes contaminated.
Crystals can also hve a much higher resistance at start when the level
is near thermal noise.
A crystal maintaining circuit should be capable of ocillating a crystal
at least 3X worse resistance than the spec.
Remember drive level is seperate to circuit activity.
--
douglas dwyer
Ian Wilson
found that poor starting is usually incorrect phase rather than gain.
In this case you usually need more lag and so more C to give the
require 180 deg lag around the gate oscillator. Also try adding a 1k
series resistor between the output of the gate oscillator (important
it is the output) and the crystal. Keep both the shunt C's on the
xtal. The extra phase shift from the series R working with the shunt
C can help ensure correct phase.
I agree with Todd - the xtal is close to the micro isn't it.
Ian Wilson
"Todd K. Moyer" <todd_...@yahoo.com> wrote:
>I would add that parasitic board capacitance adds to the intentional
>capacitance you put on the board. So you may have to go several pF lower on
>the cap values than you would otherwise expect. The fact that lowering the
>capacitance "improves it slightly" may be telling you something. I'm just
>giving you a justification to go even lower. Another engineer at my last job
>had this problem, and he had to go lower on the capacitors than he first
>expected.
>By the way, you do have the crystal fairly close to the uP, right?
>Todd
>Dave VanHorn wrote in message <7KRO2.7712$033....@news.rdc1.il.home.com>...
>>
>>
>>Peter Liew wrote in message <5cRO2.110$wc7....@news.clear.net.nz>...
>>>Hi fellas,
>>>I'm experiencing some difficulties in starting a crystal up. This
>>crystal
>>>is driven by a PIC and when reseting from standby often the crystal
>>refuse
>>>to start, but if I touch the crystal with my finger it will start.
>>
>>
>>Why is it always the PIC guys with the crystal problems...
>>Oh well.
>>
Chafik Hankour
be slightly larger in value than the other, for proper startup from standby,
anyone has an explanation for this?
Chafik
Peter Liew (mpl...@compuspec.co.nz) wrote:
: Hi fellas,
: I'm experiencing some difficulties in starting a crystal up. This crystal
: is driven by a PIC and when reseting from standby often the crystal refuse
: to start, but if I touch the crystal with my finger it will start.
: I've tried reducing the capacitive loading on the crystal which improves it
Todd K. Moyer
My experience differs with yours on this. I can recall at least 2 or 3
incidents where I have had to reduce the caps from what I had initially
calculated to get the oscillator to start reliably, once in a discrete
transistor Pierce oscillator. In the case of the discrete oscillator I had
calculated the capacitor values by assuming 60 degrees phase shift from the
amplifier output impedance working into the capacitor (I had copied the
topology out of a book which showed an emitter follower buffering the
inverting gain stage; the output resistance was set by a series resistor; I
have since come to believe that the buffer was quite unnecessary).
Your assessment of the problem seems to imply that the output impedance of
the oscillator is too low. I question whether this is true. Let me say why I
think not: Remember we are talking about the small-signal case here
(startup). The unbuffered inverter looks more like a transconductance than a
voltage amplifier, in that it has relatively high output impedance (drain
impedance of 2 FET's in saturation, in parallel). From that I would assume
something near 90 degrees of phase shift occuring at the cap that hangs on
the output, as with a gm-C integrator.
Peter, if you're still listening, let us know what works. Maybe we can learn
something.
Todd
Ian Wilson wrote in message
<7ei4kg$243$1...@reader1.reader.news.ozemail.net>...
Bruce Nepple
Peter Liew wrote in message <5cRO2.110$wc7....@news.clear.net.nz>...
Peter Liew
down to 10pF and I'm reluctant to go lower. Sometimes the weird thing is
that removing one of the caps seems to solve it for some boards. The thing
is that the crystal also provides the osc for two other chips. I suppose I
could try and get away with removing the capacitor on the osc input side,
after all their main purpose is only to add a 90 degree phase shift.
Thanks for your input,
Peter.
Todd K. Moyer wrote in message <7egsko$5p9$1...@remarQ.com>...
Peter Liew
What about flux contamination on the crystal. I've also found on some
boards that spraying flux off seem to help.
Fresh thanks and regards,
Peter.
douglas dwyer wrote in message ...
Peter Liew
Dave VanHorn wrote in message <7KRO2.7712$033....@news.rdc1.il.home.com>...
>
>
>Why is it always the PIC guys with the crystal problems...
>Oh well.
>
I did not know that there were so many out there. If there are, please
share your stories.
>Bypass caps on the uP supply?
Had no effect.
>Proper value of loading cap on the crystal? (not from someone's
>circuit, it's in the xtal's spec sheet)
I had to use Taguchi methodology to determine the best combination of
capacitors which cut down faults in half but did not kill the problem.
>Pic programmed to right oscillator mode?
Yes.
>Paralell resonant fundamental mode xtal?
No. Crystal is in series, with no series resistor to limit loop gain.
>Xtal caps going straight to Pic's ground pin?
Yes.
The interesting thing is that the crystal have no problem starting on power
on reset. It just refuse to start (unless you touch it) when you wake up
the PIC from standby mode.
Dave VanHorn
>>Bypass caps on the uP supply?
>Had no effect.
Either not enough, not placed right, or there's enough, and it's some
other problem.
>>Proper value of loading cap on the crystal? (not from someone's
>>circuit, it's in the xtal's spec sheet)
>
>I had to use Taguchi methodology to determine the best combination of
>capacitors which cut down faults in half but did not kill the
problem.
??? The only way I know to do this is start with the specified loading
C and remove about 5pF for parasitics.
>>Paralell resonant fundamental mode xtal?
>No. Crystal is in series, with no series resistor to limit loop
gain.
The pic oscillator is a paralell mode circuit (two caps to ground from
the crystal)
AFAIK, there is no need for a resistor.
You could have a bad rock, it happens, especially if it's ever been
dropped.
Mel, Steve Mellor
> Yes the crystal is fairly close to the uP. The values I'm using is already
> down to 10pF and I'm reluctant to go lower. Sometimes the weird thing is
> that removing one of the caps seems to solve it for some boards.
<important>
> The thing
> is that the crystal also provides the osc for two other chips.
</important>
> I suppose I
> could try and get away with removing the capacitor on the osc input side,
> after all their main purpose is only to add a 90 degree phase shift.
I think you just answered your own question - unless you're buffering the
oscillator before driving the other two devices. I don't know anything about
PIC, and I know very little about oscillator design (bit of a black art by all
accounts), but no doubt someone knowledgeable will be along in a minute...
Mel
Ian Wilson
What you say is true enough. I have also had to reduce C to make some
oscillators stable. My point is that reducing C is not the only thing
to do. Most gate oscillators analysis that I have seen show that
increasing C improves starting reliability at the expense of
stabilisation time. Adding the series R is a lower noise (smaller
circulating currents) of acheiving about the same.
Actually it should all lend it self to some careful analysis and
experiment. My practice in a case like this is to make it worse before
making it better so you are sure you have fixed the problem. A
1-in-a-100 failure on the bench can easily be missed but then in the
field this will damage any companies reputation. Also watch out for
the effects of heat. The common AT crystal cut (from memory) have a
series R that increases slighlty with age and temp - this could make a
marginal cct fail intermittently or progressively over time. You need
to make the osc cct stable and reliable. Check for starting after long
term elevated temp and long term cold temps (unpowered soaks). Use a
board that is showing the fault and record carefully the starting
ability before any mods and then do each mod one at a time and retest in
the most unreliable state (cold or hot). Finally take a bundle of
unreliable devices - test before modifications. Do the mod and
re-test. May sound time consuming but it is worth it for volume
production.
For the record I have not noted starting problems on either of the two
PICs I have used. I am using the standard xtal config with but choosing
a C on the high side of the suggested range.
Remember an RF engineers finger is about 10p - while a digital designers
finger (phut!) must be at least 100p :). (Before you say it I know that
in this case touching with a finger is injecting noise most likely and
can't really be used as a pointer to what direction the shunt C should
go.)
Best of luck
Ian
--
-----------------------------------------------
Considered Solutions consi...@ozemail.com.au
5 The Crescent ph: +61-2-9411-4248
Chatswood, NSW, 2067 fx: +61-2-9411-4249
Australia
Ian Wilson
> > down to 10pF and I'm reluctant to go lower. Sometimes the weird thing is
> > that removing one of the caps seems to solve it for some boards.
>
Whoaw....
Such low value for the C could well be the reason - What freq is the
xtal? My bet is now definitely that a series R along with 33pF xtals or
even a little higher would make starting reliable - *but slower* - Is
wakeup time from sleep an issue?
Also - which side of the gate osc are you driving the other chips?
Should be the output - before the (new) series R - better still buffer
with a single HC input up really close to the PIC osc. I assume the
clock signal to the other chips is *really short* - cause it has to be.
> > I suppose I
> > could try and get away with removing the capacitor on the osc input side,
> > after all their main purpose is only to add a 90 degree phase shift.
The shunt Cs are required - "only providing a 90 deg phase shift" only?
*only*? The phase shift is vital. About 180 degrees (give or take a
bit) for the gate, so the xtal cct needs to provide 180 degrees itself.
When running the xtal will look a bit inductive (it doesn't run exactly
at resonance but slighty down the reactance curve) which along with the
C's forms a C-L-C cct which provides the other 180 deg phase shift
required for oscillation. If the C is too low then the L must be big
and you are running the xtal further from resonance and so the effective
R rises. Loop gain falls and so osc is unreliable. Increasing the C
allows the xtal to run closer to resonance. Adding the series R from
gate output to the xtal and shunt C adds a little extra phase shift to
ensure that there is actually a little more than 360 deg of phase shift
available
Post you results to the thread please - I am interested.
Ian Wilson
623402
devices. bypass cap straight across pic pins is important. tracks < 1cm
2) Is the crystal too cheap perhaps. don't use solder seal xtals for long
product life. Use a 3 pin ceralok if you don't need an xtal. Is it a strip
xtal (ceramic pack or very short can) : R will be higher.
3) The value of the 2 caps in series is the xtals load capacitance. This is
purely to get "on frequency". The C value should be set to get the
oscillator to run properly, then the xtal specd for that load capacitance
to get it on freq.
4) The resistor (or capacitor) in series with the invertor output reduces
the crystal power. our strip xtals are happy at 5-20uw, some cmos oscs are
putting mW thru the xtal
5) Oscillator margin: find what the xtal R is at your oscillator power. put
a trimpot (eg 100R) in series with the xtal and adjust until it just
starts. if the trimpot R value is >=2x the xtals R, you have a saleable
product.
6) if the freq is high for the cmos device, eg if you have an XT oscillator
and a 20MHz xtal, you need to use a different type of osc. Leave off the
cap on the output side. The phase shift is provided by the integrator
action of the invertor operating above its 3dB point.
Peter Liew <mpl...@compuspec.co.nz> wrote in article
John Woodgate
il.com.au> inimitably wrote:
>Remember an RF engineers finger is about 10p - while a digital designers
>finger (phut!) must be at least 100p :).
Is this the going rate per hour or what?
--
Regards, John Woodgate, OOO - Own Opinions Only.
Phone +44 (0)1268 747839 Fax +44 (0)1268 777124.
Did you hear about the hungry genetic engineer who made a pig of himself?
Tap
What freq. Xtal/brand are you using?
Tap
On Fri, 9 Apr 1999 11:45:23 +1200, "Peter Liew"
<mpl...@compuspec.co.nz> wrote:
>Yes the crystal is fairly close to the uP. The values I'm using is already
>down to 10pF and I'm reluctant to go lower. Sometimes the weird thing is
>that removing one of the caps seems to solve it for some boards. The thing
>is that the crystal also provides the osc for two other chips. I suppose I
>could try and get away with removing the capacitor on the osc input side,
>after all their main purpose is only to add a 90 degree phase shift.
>
Dave VanHorn
>> The thing
>> is that the crystal also provides the osc for two other chips.
This can be bad. Do they spec a drive level and max load for that
output?
I ran into this exact problem (not a pic though) The designer decided
to do this to save cost, but I remarked that there was no loading
spec, and therefore, we couldn't count on it working. His reply was
"all 10 of my prototypes work:". Sure enough, they all worked.
A couple months later, I get a panic call from the boss to depart for
Kaohsiung on Christmas day, first available flight. It seems that in
production, only half of them would start up at all.
Point being, if it's not DESIGNED to drive a load, you can't count on
it doing so.
If it works it's a bonus, and when it craps out on you, don't go
crying to uChip.
IF there's a drive level and maximum loading spec on that output, then
just make sure you're within spec, and it should be working.
FWIW: I just got some crystals for another application from ALS
Here's the guts of the spec sheet:
Freq: 18.048750
Load: 32pF
Temp 25C
Resistance (xtal @ series resonance) 24
Drive level 2mW (So much for overdriving them easily)
Shunt C 5pf min, 7pf max
Tolerance .0025 (MHz)
Calibration: Min:18.048298 Max 18.049201
Another rock, series mode is same except that it has no load cap
specified, 40 ohms resistance.
Motto: Get the specs on your rocks. Digikey will fax detailed spec
sheets.
R. Zuidema
-René-
Tap
loading effects from them. If that works, reconnect using a series
resister instead.
Tap
>> The thing
>>is that the crystal also provides the osc for two other chips. I suppose I
You should have mentioned this nonstandard circuit in the begining
douglas dwyer
<r.zu...@pijnenburg.nl> writes
>1 M across the osc terminals?
>
>-René-
emitter amp is employed with the customary shunt caps from base and
collector to ground the crystal with 30pf in series (only to meet
manufacturers input condition if your worried about ppm setting
tolerance) from base to collector.
Note that that if the collector base resistor is 100k and the supply
resistor to Collector is 10k then the impedances will be lower than most
IC oscillators so the shunt caps can be a more healthy 100pF or so
depending on frequency..
Feed the collector o/p by resistor or cap to the oscillator circuit
input gate. These single transistor maintaining circuits are much more
hygenic than gate oscillators.
Note CMOS gate oscillators have a non conducting centre region of their
transfer characteristic, gain obviously goes to zero in this region and
though the FB resistor to bias maintains at some slightly conducting
region the actual V/V is very uncertain.
--
douglas dwyer
Dave VanHorn
>- Frequency of crystal is 3.579MHz. (Standard freq used to encode
and
>decode DTMF tones). Those are my other chips that obtains their
clock input
>from the crystal.
FWIW, You'll suffer some EMI running the clock around like that. Make
REAL sure you have a good low Z ground between the pic and the
"customer" chips, including if at all possible, a ground track along
the same path as the clock.
You may be better off with separate rocks. It is about the cheapest
rock made.
Nitin Joshi
Nitin
Peter Liew wrote:
> Fresh thanks to all who have participated so far. I appreciate all your
> input. For your information...
>
> - Frequency of crystal is 3.579MHz. (Standard freq used to encode and
> decode DTMF tones). Those are my other chips that obtains their clock input
> from the crystal.
>
> Unfortunately its Saturday today so I'm not able to try anything until
> Monday. Office is locked up. Please be patient for update on results.
> Besides, I've got to spend some time with family and do some housework.
>
> Fresh thanks and regards.
>
> Peter.
Peter Liew
Peter Liew
Ian Wilson wrote in message <370D6BA2...@pop.ozemail.com.au>...
>> > Yes the crystal is fairly close to the uP. The values I'm using is
already
>> > down to 10pF and I'm reluctant to go lower. Sometimes the weird thing
is
>> > that removing one of the caps seems to solve it for some boards.
>>
>
>Whoaw....
>
>Such low value for the C could well be the reason - What freq is the
>xtal? My bet is now definitely that a series R along with 33pF xtals or
>even a little higher would make starting reliable - *but slower* - Is
>wakeup time from sleep an issue?
>
Frequency is 3.579MHz. Wakeup time is important.
>Also - which side of the gate osc are you driving the other chips?
>Should be the output - before the (new) series R - better still buffer
>with a single HC input up really close to the PIC osc. I assume the
>clock signal to the other chips is *really short* - cause it has to be.
>
Driving from the output. Have not tried out the series R yet. How short is
*really short*?
>> > I suppose I
>> > could try and get away with removing the capacitor on the osc input
side,
>> > after all their main purpose is only to add a 90 degree phase shift.
>
>The shunt Cs are required - "only providing a 90 deg phase shift" only?
>*only*? The phase shift is vital. About 180 degrees (give or take a
>bit) for the gate, so the xtal cct needs to provide 180 degrees itself.
>When running the xtal will look a bit inductive (it doesn't run exactly
>at resonance but slighty down the reactance curve) which along with the
>C's forms a C-L-C cct which provides the other 180 deg phase shift
>required for oscillation. If the C is too low then the L must be big
>and you are running the xtal further from resonance and so the effective
>R rises. Loop gain falls and so osc is unreliable. Increasing the C
>allows the xtal to run closer to resonance. Adding the series R from
>gate output to the xtal and shunt C adds a little extra phase shift to
>ensure that there is actually a little more than 360 deg of phase shift
>available
>
Because I've got the two other chips grabbing the clock via capacitors, I
thought that perhaps that they could be providing the 90 degree phase shift
on that side. I've just notice my typo, I meant removing the cap on the osc
out side of the PIC (other two chips osc connected here). Why I mentioned
it is because it had worked on some units (yet to check further). I've yet
to try adding the series resistor (board layout limitations makes it
difficult), but wouldn't it decreases the loop gain which may also worsen
startup ability?
>Post you results to the thread please - I am interested.
>
Will do, when I get to try it out on Monday. I'll appreciate your patience
in the meantime.
Ian Wilson
>>- Frequency of crystal is 3.579MHz. (Standard freq used to encode
>and
>>decode DTMF tones). Those are my other chips that obtains their
>clock input
>>from the crystal.
>FWIW, You'll suffer some EMI running the clock around like that. Make
>REAL sure you have a good low Z ground between the pic and the
>"customer" chips, including if at all possible, a ground track along
>the same path as the clock.
>You may be better off with separate rocks. It is about the cheapest
>rock made.
Separate xtals can make EMI worse very occaisionally as they are
slightly different frequencies and so can generate high and low freq
beat signals as the current pulses mix in other non-linear junctions.
This is a real problem in low noise RF work where clock distribution
needs careful thought. With a few crystals it is quite easy to get
beat frequencies in the 100's Hz to kHz range which can completely
stuff up low noise analog circuits. The harmonic mixing products can
extend into VHF.
For only digital ccts with short traces multiple crystals may be
better.
Ian Wilson
--------------------------------
Considered Solutions
consi...@ozemail.no.spam.com.au
(do the no spam thing to make a valid email address)
Ian Wilson
>Frequency is 3.579MHz. Wakeup time is important.
If wakeup time needs to be very short maybe you could considered using
a RC osc form which starts straight away and a LF xtal on Timer 1 to
allow you to calibrate your RC osc on the fly. This is what I do.
Some of the PICs allow a seperate low freq (kHz to 200 kHz max) osc
designed for 32 kHz clock xtals. I think it hags off Timer 1 from
memory and can run during sleep to provide wakeup.
In my application the wakeup time of the xtal osc (osc startup plus
1024 cycles) was way too long.
A lower Q moderately accurate ceramic resonantor will start much
faster than a xtal but since the PIC has a 1024 cycle osc startup
timeout this may not make much difference to when your cct starts to
run after wakeup.
PS I am only really familiar with the 16C554 and 16C73/74 devices.
Bob Camp
>
> Hi fellas,
> I'm experiencing some difficulties in starting a crystal up. This crystal
> is driven by a PIC and when reseting from standby often the crystal refuse
> to start, but if I touch the crystal with my finger it will start.
>
> I've tried reducing the capacitive loading on the crystal which improves it
> slightly but does not eliminate the problem.
>
> Has anyone experienced this problem before? What solutions could you
> suggest for me to try?
>
> Thanks in advance.
>
> Peter.
>
Hi
The ideal gain element for a crystal oscillator (assuming two pin and
Pierce) is a well controlled transconductance with high impedance (several
MegOhm) biasing network.
It is quite possible, even probable, that your pic uses an inverter as the
gain element for the crystal oscillator, maybe even a NAND gate since it
may be switched into standby. Since the pic is primarily a digital circuit
the process is unlikely to have any high resistivity material available.
The inverter will therefore be biased by a lowish value of resistor, or
possibly a mosfet, although even this this may be too much analogue for
some designs.
Anyhow... The net result of all this is that there will be two things
wrong with the circuit from the start.
Transconductance of the amplifier will not be well controlled. In fact the
output conductance is likely to be quite high. Secondly the biasing
network is likely to be too low an impedance.
The next important fact, that is scarcely known outside of oscillator
design circles, is that as well as there being a minimum gm
(transconductance) required for oscillation to be sustained there is also a
maximum gm [1,2]. Above which the oscillator will not work.
Why do manufactures use an inverter? Well its simple and can be made on
any digital process. Add to this the fact that the typical logic clock can
tolerate reasonable jitter.
Let us digress for a moment and consider the inverter as an amplifier. In
its DC bias state the small signal gain is likely to be at a maximum.
(There are reasons why a simple resistor may not achieve this condition but
we may reasonably assume the the designer has arranged for this to happen.)
The transfer characteristic of an inverter is nonlinear. For example most
of the output voltage swing may occur for a few tens to hundreds of
millivolts of input swing. (Just try wiring a pot to the input and see if
you can adjust it for mid swing at the output.) The net result of all this
rambling is to come to the point that small signal gain of the inverter
_reduces_ as the input amplitude _increases_. The more astute of you, no
doubt, are now seeing how this all fits together.
For the case where the circuit is powered up: If the oscillator is not
going then the amplifier gain is too high to allow it to start up, but, if
it is going then the amplifier gain is reduced enough for the oscillations
to be maintained.
How does the oscillator start up? Well if the circuit is biased at
equilibrium then there is only noise acting to move it away from
equilibrium. In fact the initial part of the amplitude growth is
exponential. It reduces from exponential when nonlinearities in the system
start to reduce the average gain. So, it sits there doing nothing because
the noise in the system is not large enough to move the amplifier into the
lower gain regime. When you put your finger on the crystal you inject
enough signal to achieve the start up amplitude.
Often start up from noise alone is slower than would be desirable. This
time can be improved by inducing some signal into the loop. Analysis of
the startup conditions [1] have shown that essentially the highest current
through the resonator is best. Now it is not practical to put a finger on
the crystal each time to start it, but it turns out that a start condition
where both ends of the resonator are connected to one supply and then
released is pretty much near optimum. Just as when the circuit Initially
powers up. Add to this the fact that the inverter gain will be less when
the power supply is low and this allows the circuit to start reliably and
fast from switch on.
When the circuit is switched to standby it may be that one input of a NAND
is taken low. If this is the case then initial conditions for the crystal
are such that it will have a slow start, possibly taking hundreds of micro
seconds to get to a position where start up can occur. If this is the case
then that would also explain why even though the amplifier gain were
starting from a low value (as the gate switched on) oscillation still did
not start.
My guess is that start up will be found to be more reliable at lower supply
voltages and worse at higher supply voltages. Probably worse at low
temperature and better at high temperature as well (although this is more
complicated).
Ok, this may explain everything observed on the board (although I could be
entirely on the wrong track of course), what is to be done about it?
Fortunately there has been some good papers published on this [1,2] and the
simple answer is to increase the capacitances at input and output of the
gain element. The overall effect of this is to reduce phase shifts due to
the finite resistances. For a plain complementary inverter the worst
component will be due to the output conductance. Therefore increasing
capacitance on the output side should be beneficial. Looked at another way
this increases the maximum transconductance that will allow oscillation to
start.
On the down side the network around the crystal will not be what the
crystal is specified for so frequency may be off a little but my guess is
that that aspect will not be important.
On the issue of using this clock for other boards. It does not appear
superficially to be a problem since the oscillator does work under some
conditions. However, biasing of the oscillator is high impedance and
therefore coupling to the external buffer _must_ be capacitive. You will
not be able to match adequately for resistive (in fact there is a chance
that all the problems could be caused by this buffer debiasing the
amplifier or otherwise modifying its gain, but presumably you checked
that). This capacitor is in parallel with any other capacitance on that
node and so adds to the total (need to calculate C in series with Cin of
buffer). The nonlinear loading by this buffer will contribute to jitter
but jitter will be poor anyway with this type of design. The buffer may be
driven off either end of the crystal, curiously the input side is probably
best.
One thing to be aware of is that if you are transferring data from board to
board then that method of distributing the clock may be inadequate as
jitter could cause violation of setup or hold times. Variations in
oscillator amplitude for example will modify clock skew between the boards.
The suppositions about the system in question are my contribution here but
for a more detailed discussion on oscillator design issues you may want to
look at:
[1] "Start Up Time of CMOS Oscillators", A Rusznyak, IEEE Trans. Cir and
Sys, CAS-34, No 3, March 1987 pp259-268
[2] "Conditions for Start-Up in Crystal Oscillators", M. A. Unkrich,
R. G. Meyer, IEEE Trans. Sol. State Cir. Vol SC-17 No 1 Feb 1982, pp87-90.
Of course this is just speculation based on my guess as to how the
oscillator is implemented and what conditions prevail. It will probably
turn out that the control input was left open circuit or some such. Well
it was worth a go :)
Hope this helps.
Bob Camp
--
Cygnus Technical Consulting
Analogue and Digital IC Design.
b...@hadron.demon.co.uk
http://www.hadron.demon.co.uk/
Todd K. Moyer
Thanks for spending the time to put up such a thorough post.
I thought you might like to see another reference, if you have not already:
"High-Performance Crystal Oscillator Circuits: Theory and Application",
Vittoz, et al, IEEE Journal of Solid State Circuits, June 1988, pp. 774-783.
This paper also describes the condition of too much transconductance
preventing oscillation. In addition there are discussions of some other
effects, such as the consequences of extreme non-linearity typical in a uP
oscillator.
Todd
Bob Camp
Hi Todd
Many thanks for the feedback.
I just happen to have a copy of the Vittoz paper to hand. This is an
excellent paper, in my view a classic, with a good reference list, among
them the two I quoted in the earlier post. The main interests of Eric
Vittoz et al in regard of this paper is for low power and good long term
frequency stability. Primarily for watch and clock chip applications where
long term operation with a single battery cell is required. I have used
derivatives of this design where low power and low jitter is required.
The reason I did not quote the paper was because it is aimed at precision
oscillator design. Although (as you say) the inverter type oscillator is
covered, to the effect that it is not good enough for these types of
applications. The two papers quoted cover relevant material with
experimental results. In the Rusznyak paper for example there are
oscillograms showing start up.
Thanks once again.
Bob
"Todd K. Moyer" <todd_...@yahoo.com> writes:
>
> Bob,
>
> Thanks for spending the time to put up such a thorough post.
>
> I thought you might like to see another reference, if you have not already:
> "High-Performance Crystal Oscillator Circuits: Theory and Application",
> Vittoz, et al, IEEE Journal of Solid State Circuits, June 1988, pp. 774-783.
>
> This paper also describes the condition of too much transconductance
> preventing oscillation. In addition there are discussions of some other
> effects, such as the consequences of extreme non-linearity typical in a uP
> oscillator.
>
> Todd
>
> >The next important fact, that is scarcely known outside of oscillator
> >design circles, is that as well as there being a minimum gm
> >(transconductance) required for oscillation to be sustained there is also a
> >maximum gm [1,2]. Above which the oscillator will not work.
> >
>
Peter Liew
I have to reconfigure our production HP in-circuit tester for a new board,
which may take some time. I will have to continue this discussion later in
the week.
I appreciate your help so far.
Fresh regards,
Peter.
InnVec
Impedance or how "hot" xtl is determines
startup.New crystals can age 20% after
6 mos time. Is this a 72khz clock crystal in
a low-pwr app?
Try a higher ,within-spec op voltage
Regards
Bob Deaton
InnoVec Technology
Peter Liew
I've got an update, please look at "Crystal starting problem - I'm back" in
this newsgroup dated 20th April 99.
I hope I'm no breaching any newsgroup protocols by doing this.
Peter.
BA
On Thu, 8 Apr 1999 16:39:30 -0700, "Todd K. Moyer"
<todd_...@yahoo.com> wrote:
Over the years, (I'm not sayin' how many) I've been
burned by this repeatedly, not just on PIC's but all
the others, too.
I have, of late shifted, to ceramic resonators, and
although they drift some over time, they don't cause
those gut-wrenching calls at 2AM when the factory
is shutdown because the "crystals won't oscillate".
Frankly, I've experienced a LOT of crystal variation,
and resonators FIX the problem for 95% of all applications.
AND they are cheaper and less susceptible to shock,
to boot...
Just got through with a 3.58M ceramic res design, on
a PIC16C73B SOIC. Oscillator starts RELIABLY from
a cold start via interrupt.Every time.
--Bob