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.
Regards,
J
LPC2106: Overclocking the CCLK /PCLK
Started by ●April 18, 2010
Reply by ●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.
Richard
> 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
Reply by ●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
> > 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 ●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).
>
> --- 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 ●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
>
>
> --- 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 ●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
>
> 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 ●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 ?
{:-)
>
> --- 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 ●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).
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 ●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
> 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 ●April 20, 20102010-04-20
--- 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
>
> --- 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
