On Sunday 18 April 2010 22:31:46 voltz56 wrote: > My dev system has a 16MHz crystal so it can only run
at 48MHz
> without overclocking it i.e. 16 x 3. One multiplier higher would
> give me 64MHz. The device max is rated as 60MHz.Is it safe to push
> past this.
Dangerous. Overclocking is guaranteed to cause failures. Some
catastrophic, some unpredictable functional failures. Except for
experimental purposes, avoid OC like the plague.
Having said that, a+10% variation should work with a bit of luck.
--- In l..., "rtstofer" wrote: >
> --- In l..., "voltz56" wrote:
>
> > Well if it were for production then I would not.., but it annoys me that Im
stuck at 48MHz unless I do. I will probably just play it safe though. Ive had
enough problems development already, I dont feel like incurring any more.
> >
> > Regards,
> > J
> > Change the crystal! You would be much better off with 14.7456 MHz because
baud rates work properly and the 2106 doesn't have a fractional baud rate
divider.
>
> Richard
>
That would be the most sensible solution all around. Think I will do that.
Thanks again,
J
Reply by rtstofer●April 19, 20102010-04-19
--- In l..., "bobtransformer" wrote:
> I would not overclock a production product, BUT if I
did have to do that, I would first bring the clock up to where I saw it fail to
work, and then drop the clock speed down to somewhere in between max
specification clock frequency and max measured speed. For instance, if I found
that a 72 MHz max (spec'd) clocked part worked up to 100 MHz, I might take
it up to 80 MHz and feel fairly safe. But even then, I might test at least
some of each production batch (date code) of processors to make sure they are
consistent with the over clocked speeds.
>
> boB
>
After reading the various errata, I have come to the conclusion that these chips
barely function when operated within specs. I certainly wouldn't want to
overclock them.
What's the point? There are MANY faster processors including most of the
Cortex M3 devices. If that isn't enough speed, the Blackfin runs at 500
MHz and there are others running 600 MHz.
Richard
Reply by Michael J Scott●April 19, 20102010-04-19
The frustration you feel about the relative functionality of NXP processors
vs. specifications is well founded, but also not unique to NXP. This has
been an industry wide methodology from the beginning. I have been designing
embedded systems since the Intel 8008 (my first) and each semi company has
been doing the same thing to greater and lesser degrees. One company, and I
will not use any names, used to publish specifications and would not
actually fab any parts until enough people called sales looking for them,
other companies fab parts only once or twice per year (so errors are only
fixed at extended intervals, and if production volumes are not high, they
may never get fixed). If you do design for any length of time you create a
priority list of companies you use for new designs. There are still some
companies whose products I will never design into a product.
If you want to be on the point of the arrow, you will spend a lot of time
finding errors and working around them, its just part of the job.
Michael Scott
SELDS, Inc.
_____
From: m...@ymail.com [mailto:m...@murphy.pri.ee]
Sent: Sunday, April 18, 2010 10:33 PM
To: l...
Subject: [lpc2000] Re: LPC2106: Overclocking the CCLK /PCLK
--- In lpc2000@yahoogroups .com,
"rtstofer" wrote: >
> --- In lpc2000@yahoogroups .com, "bobtransformer" wrote: > > > After reading the various errata, I have come to
the conclusion that these chips barely function when operated within specs. I certainly
wouldn't
want to overclock them. > >
> > I hadn't read any of that, but I wouldn't doubt there is
something written regarding that. > I wasn't talking about errata related to speed,
per se. I was just referring to the number of things that just don't work or don't
work
properly (as defined by the User Manual). Sometimes there are work-arounds,
sometimes not. But they all indicate a rush to market. >
> Then again, uCs are so complex that it is a wonder they can be designed at all. These things are pretty amazing. >
> Richard
>
NXP has rush to market.
Prototyping normally :
1)proto for proof of concept.
2)1 proto for fixing bugs
3)production proto, testing ALL features.
4)production
NXP :
1) production, let clients test and find out bugs.
I use new NXP products when I have LOT of spare time to deal with bugs.
My vision how NXP improves quality:
1)Buy other MCU and copy hardware. (For example BlueStrek LH75401 LCD
controller is in LPC2478 with minimal modifications)
2) If clients complain to much then add to errata and maybe later with new
revision try to fix.
Hardware bugs increase design time and using MCU wich has lot of hardware
bugs will blow all deadlines.
Some good things:
specification structure mostly programmers friendly (compared to renesas
where you need to scroll up and down >100 page to get full picture).
Reply by bobtransformer●April 19, 20102010-04-19
--- In l..., "Donald H" wrote: >
> --- In l..., "voltz56" wrote:
> >
> > Well if it were for production then I would not.., but it annoys me that Im
stuck at 48MHz unless I do. I will probably just play it safe though. Ive had
enough problems development already, I dont feel like incurring any more.
> >
> > Regards,
> > J
> > Spoken like a real hacker, not engineer.
>
> to quote something I found on the internet a long time ago.
>
> "Engineering is building something with what you've got, not with what
you wish you had"
>
> don
> Gee.... Can't you just stick 2 48MHz parts in parallel and get 96MHz
?
{:-)
Reply by Donald H●April 19, 20102010-04-19
--- In l..., "voltz56" wrote: >
> Well if it were for production then I would not.., but it annoys me that Im
stuck at 48MHz unless I do. I will probably just play it safe though. Ive had
enough problems development already, I dont feel like incurring any more.
>
> Regards,
> J
>
Spoken like a real hacker, not engineer.
to quote something I found on the internet a long time ago.
"Engineering is building something with what you've got, not with what you
wish you had"
don
Reply by bobtransformer●April 19, 20102010-04-19
--- In l..., "rtstofer" wrote: >
> --- In l..., "bobtransformer" wrote:
>
> > I would not overclock a production product, BUT if I did have to do that, I
would first bring the clock up to where I saw it fail to work, and then drop the
clock speed down to somewhere in between max specification clock frequency and
max measured speed. For instance, if I found that a 72 MHz max (spec'd)
clocked part worked up to 100 MHz, I might take it up to 80 MHz and feel fairly
safe. But even then, I might test at least some of each production batch (date
code) of processors to make sure they are consistent with the over clocked
speeds.
> >
> > boB
> > After reading the various errata, I have come to the conclusion that these
chips barely function when operated within specs. I certainly wouldn't
want to overclock them.
I hadn't read any of that, but I wouldn't doubt there is something
written regarding that.
I've tried changing the PLL divider and the LPC2366 seemed to run fine at
around 100 MHz or so... Unless there is some kind of internal
limit that automatically keeps the part from being overclocked that way, it was
working just fine. I don't remember if I actually checked any operations
though after doing that.
Another thing I would want to do when trying to find out how fast an overclocked
part will go would be to heat it up with, say, a hairdryer and see if it kept
working.
About 5 years ago, I tore my hair out trying to get Atmel ATMega32 parts to run
at 16 MHz, only to later find out that Atmel had bad silicon that would mess up
at over 12 MHz. One year of a nightmare that would not go away and a company in
denial.
boB
>
> What's the point? There are MANY faster processors including most of the
Cortex M3 devices. If that isn't enough speed, the Blackfin runs at 500
MHz and there are others running 600 MHz.
>
> Richard
>
Reply by "mur...@ymail.com"●April 18, 20102010-04-18
--- In l..., "rtstofer" wrote: >
> --- In l..., "bobtransformer" wrote:
> > > After reading the various errata, I have come to the conclusion that these
chips barely function when operated within specs. I certainly wouldn't
want to overclock them.
> >
> > I hadn't read any of that, but I wouldn't doubt there is something
written regarding that.
> I wasn't talking about errata related to speed, per se. I was just
referring to the number of things that just don't work or don't work
properly (as defined by the User Manual). Sometimes there are work-arounds,
sometimes not. But they all indicate a rush to market.
>
> Then again, uCs are so complex that it is a wonder they can be designed at
all. These things are pretty amazing.
>
> Richard
>
NXP has rush to market.
Prototyping normally :
1)proto for proof of concept.
2)1 proto for fixing bugs
3)production proto, testing ALL features.
4)production
NXP :
1) production, let clients test and find out bugs.
I use new NXP products when I have LOT of spare time to deal with bugs.
My vision how NXP improves quality:
1)Buy other MCU and copy hardware. (For example BlueStrek LH75401 LCD
controller is in LPC2478 with minimal modifications)
2) If clients complain to much then add to errata and maybe later with new
revision try to fix.
Hardware bugs increase design time and using MCU wich has lot of hardware bugs
will blow all deadlines.
Some good things:
specification structure mostly programmers friendly (compared to renesas where
you need to scroll up and down >100 page to get full picture).
Reply by rtstofer●April 18, 20102010-04-18
--- In l..., "bobtransformer" wrote: > > After reading the various errata, I have come to
the conclusion that these chips barely function when operated within specs. I
certainly wouldn't want to overclock them.
>
> I hadn't read any of that, but I wouldn't doubt there is something
written regarding that. I wasn't talking about errata related to speed, per se. I was just
referring to the number of things that just don't work or don't work
properly (as defined by the User Manual). Sometimes there are work-arounds,
sometimes not. But they all indicate a rush to market.
Then again, uCs are so complex that it is a wonder they can be designed at all.
These things are pretty amazing.
Richard
Reply by rtstofer●April 18, 20102010-04-18
--- In l..., "voltz56" wrote:
> Well if it were for production then I would not..,
but it annoys me that Im stuck at 48MHz unless I do. I will probably just play
it safe though. Ive had enough problems development already, I dont feel like
incurring any more.
>
> Regards,
> J
>
Change the crystal! You would be much better off with 14.7456 MHz because baud
rates work properly and the 2106 doesn't have a fractional baud rate
divider.