EmbeddedRelated.com
Forums

Flash Utility Hell..

Started by James Dabbs May 7, 2004
> 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
 



An Engineer's Guide to the LPC2100 Series

--- 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



> > 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
 



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


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


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
 


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..



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




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



> 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