> The oscillator requires quite large value capacitors - try 33 pF.
It really depends on the Xtal, rather than the clock oscillator
itself.
Normally you would load the crystal with its actual load capacitance.
Ultimately the caps also affect start up time and reliability of
oscillation.
It depends on whether the (assumed Pierce) oscillator is implemented
as
a NOT gate, or with a FET. (generally you can tell whether the
oscillator
needs a bias resistor or not)
Sometimes the oscillator's drive can be a bit low, depending on
silicon.
For some Xtals, the load caps might need optimising a bit, but with most MCUs you don't have that luxuary since you need a 50% dutycycle
(unless you're using the PLL, then it's OK)
Ideally, the input cap dictates the loading of the crystal, and the output
cap
sets the phase shift for the oscillator.
A good rule of thumb would be to use double the load value of the
Xtal
on either side, so it depends on the Xtal that you're using.
A typical CL pF Xtal would eg. use 27 pF on either side.
You can get other problems too, like the Xtal can go into Third Overtone
etc.
(Anyone ever used the P300 of Intellon ?? 3OT problems galore :-)
Best is to use a good quality, fundamental Xtal with low ESR and low load
capacitance
for good startup.
This area is too often overlooked.
Xtal oscillators aren't just "throw it in" kind of circuits.
The industry tends to refer to "Computer Grade" Xtals, which have the
higher
ESR and load capacitance, a dangerous combination at times !
-- Kris
|
|
Flash Utility Hell..
Started by ●May 7, 2004
Reply by ●May 7, 20042004-05-07
Reply by ●May 7, 20042004-05-07
--- In , "microbit" <microbit@c...> wrote: > > The oscillator requires quite large value capacitors - try 33 pF. > > It really depends on the Xtal, rather than the clock oscillator itself. [deleted] Philips actually recommends using larger value capacitors, there is a table in the user manual on page 39 that suggests values of 58 pF for a 30 pF crystal load capacitance and Rs < 50R. Leon |
|
Reply by ●May 7, 20042004-05-07
> > It really depends on the Xtal, rather than the clock oscillator
> itself.> [deleted] > > Philips actually recommends using larger value capacitors, there is a > table in the user manual on page 39 that suggests values of 58 pF for > a 30 pF crystal load capacitance and Rs < 50R. > > Leon I see a table with recommended caps for various load cap. crystals (10, 20,
30 pF),
but no recommendation to use _large_ caps ?
I didn't mean to contradict you Leon, just that Xtal oscillators are
very little understood
beasties at times, and many just bang it in without knowing their actual
load capacitance,
but considering it is the heart of any MCU system, it should be given MUCH
more attention.....
(regarding runtime reliability). Notwithstanding layout issues...
I hope the brief before clarfied it a little.
Mayge Philips_apps could clarify whether the oscillator indeed is a Pierce,
and whether it's
a NOT gate or a FET ???
This will help in future.
B rgds
Kris
|
|
Reply by ●May 7, 20042004-05-07
James I have an LPC board running with a 14.7456MHz crystal and it is solid for both JTAG and Download. However, even though the crystal is parallel resonant w/ 18pf load, the circuit has 39pfd on both sides of the crystal - not sure where we got that piece of info. Anyway, it's something you might try. -Bill On Fri, 7 May 2004 12:37:02 -0400, James Dabbs wrote: > Another question. If the LPC is being driven by an oscillator, has > the output of the osc been divided down and capacitively coupled to > the LPC? Direct drive from an external osc will allow the LPC to > 'almost' work but because the waveform is distorted, the problem will > show up when trying to download to flash. Bill, In this case, it's a quartz crystal, connected directly to the processor pins, coupled to ground with 18pF caps. I should note that we started off with a 19.6608MHz crystal, and could not get the boot loader to do much more than echo back the '?' and then go into a very strange state. Dropping the freq got it working in 'hyperterm' mode, but not with the ISP loader. We've already changed parts once, and the layout is bypassed very well, with the regulator at the LPC and 10uF and .1uF chip caps right up on the 3.3V and 1.8V supply pins. Nevertheless, supply noise is still something we're thinking about. -James Yahoo! Groups Links |
Reply by ●May 7, 20042004-05-07
At 04:49 AM 5/8/04 +1000, you wrote: >I didn't mean to contradict you Leon, just that Xtal oscillators are very >little understood >beasties at times, and many just bang it in without knowing their actual >load capacitance, >but considering it is the heart of any MCU system, it should be given MUCH >more attention..... >(regarding runtime reliability). Notwithstanding layout issues... > >I hope the brief before clarfied it a little. > >Mayge Philips_apps could clarify whether the oscillator indeed is a >Pierce, and whether it's >a NOT gate or a FET ??? >This will help in future. This seems to be one of those little spoken of issues. Hitex had a section on this in one of their white papers "Insider's Guide to Planning 166 Family Design" (http://www.hitex.com/download.html) Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " Kelvin Throop, III |
Reply by ●May 7, 20042004-05-07
Robert wrote :
> This seems to be one of those little spoken of issues. Hitex had a section > on this in one of their white papers "Insider's Guide to Planning 166 > Family Design" (http://www.hitex.com/download.html) > > Robert Some oscillators will have trouble driving a Xtal properly, some will drive
a Xtal
too hard.
Since the LPC2000 oscillator specs output caps as high as 56 pF, I doubt it
would
have drive issues. A crystal that is driven too hard will age much quicker,
and will
ultimately fail after a relatively short time.... A series resistor can fix
this. (also avoids 3OT)
In case startup and/or runtime is an issue, the Xtal does not necessarily
have to be
loaded with its optimal load capacitance. This mainly sets the proper
frequency within
say 50 PPM, but in an MCU that's typ. a peripheral issue.
The output caps can be decreased where a Xtal for example has a so-so
ESR.
This will provide a bit more drive, and then the input cap can be adjusted
accordingly
to get the suitable phase shift for reliable oscillation.
If the Xtal clock is actually cclk, then however the 2 caps need to stay ~
equal in value
to maintain a 50 % dutycycle, as otherwise it will affect R/W timing in the
CPU.
In that case the values can be dropped a bit to get a better startup and
sustained oscillation.
In a marginally high ESR scenario however, a good quality Xtal should be
used for production
though, for it's hard to characterize the oscillator in production
over temperature.
Always bear in mind that with thru-hole, HC49S (low profile) crystals
have a higher ESR
than their full profile HC49 buddies.
-- Kris
|
Reply by ●May 7, 20042004-05-07
This board does not use RS232 control lines to reset the chip and set P0.14 Using LPC21ISP.EXE and hacking the source a bit to give me a second to reset the part AFTER the port is opened, but BEFORE it sends the first '?' gets me much further. This utility manages to synchronize, set the oscillator value, unlock, read the bootcode version, read the part ID, and then issue the first write command.. BUT.. Then it fails because the echo-back of the UUEncoded write data has a couple of bit errors in it. When I comment out this failure detection, I get a CRC error from the LPC at the end of the block, meaning that it is probably seeing bit errors as well. On the host side, the errors are generally 1 bit per symbol. With clock jitter, I would expect all kinds of things to give out before a 9600 baud RS-232 connection. And, as far as I can tell, the oscillator circuit is OK. Looking at it with a scope is a clean sine wave. We're going to put a spectrum analyzer on it, but I'm betting this is a power-supply decoupling issue, either with the LPC or the MAX232.. I've got a bag of caps, and I'm not afraid to use them.. |
|
Reply by ●May 7, 20042004-05-07
Yes, to actually get back to topic, hmm. Might seem silly, have you checked that you have proper RS232 GND path between host and PC ? That kind of thing would exhibit the kind of things you see too maybe. But of course manually talking to the bootloader works OK so, hum. If you have regular bit errors in each symbol/char, then I'd suspect a noisy or even sagging supply line as well. That could account for things working OK when you manually sync with the bootloader... -- Kris > This board does not use RS232 control lines to reset the chip and set > P0.14 Using LPC21ISP.EXE and hacking the source a bit to give me a > second to reset the part AFTER the port is opened, but BEFORE it sends > the first '?' gets me much further. This utility manages to > synchronize, set the oscillator value, unlock, read the bootcode > version, read the part ID, and then issue the first write command.. > BUT.. Then it fails because the echo-back of the UUEncoded write data > has a couple of bit errors in it. When I comment out this failure > detection, I get a CRC error from the LPC at the end of the block, > meaning that it is probably seeing bit errors as well. On the host > side, the errors are generally 1 bit per symbol. > > With clock jitter, I would expect all kinds of things to give out before > a 9600 baud RS-232 connection. And, as far as I can tell, the > oscillator circuit is OK. Looking at it with a scope is a clean sine > wave. We're going to put a spectrum analyzer on it, but I'm betting > this is a power-supply decoupling issue, either with the LPC or the > MAX232.. > > I've got a bag of caps, and I'm not afraid to use them.. > -- ------ > Yahoo! Groups Links > > a.. To |
Reply by ●May 7, 20042004-05-07
OK.. The tant that bypassed the MAX232 had a good solder joint, but the *pad* had cracked during rework (it was originally put on backwards). So, there was insufficient bypass for the RS232 driver and therefore 3 days of frustration. After fixing this, it works reliably at 9600 and 19200, but not 38400. Thanks for all the help.. I'm hooking up the secondary JTAG port now, so I'll probably be back in a minute.. James Dabbs, TGA |
|
Reply by ●May 7, 20042004-05-07
> I'm hooking up the secondary JTAG port now, so I'll probably
be back > in a minute.. ..and the secondary JTAG port works! I guess the law of averages is valid after all. SO.. The moral of this story is: (1) if your FLASH ISP software is behaving badly, check the quality of the target RS232 transceiver's power supply, and (2) the secondary JTAG port "just works" -James Dabbs, TGA |