Rick Collins wrote:
> There are two possibilities. One is that your chip is just a really
> fast chip. It happens. There is always variation in the
> manufacturing process. The specs have to allow for the worst case in
> several ways, process, voltage and temperature.
>
> The other possibility is that the chip really isn't running at 96 MHz.
> Maybe there is a mistake in the setup and it is running at some other
> speed.

There is a third possibility. Maybe only a subset works and the test
cases he used only used that subset. I accidentally overclocked a chip
once and the only observable fault was the baud rate wouldn't set
correctly (it was lower than expected).

Robert

Great points, thanks Cliff.

Jeremy

--- In A..., "techguy2000" wrote:
>
> --- In A..., "jeremywang2008" wrote:
> >
> > Thank you all, guys.
> >
> > Now I believe I can't do it, but I'm wondering why 7XC256 can be
> > overclocked to that high and just working well.
> >
> > To Kris:
> > I also tried your solution, set PLL out to 192MHz, then divide by 2,
> > but it fails too.
>
> You: 1) probably just had a good chip and 2) probably weren't
> hitting any temperature extremes.
>
> Processors that are speed graded often use the same core and the
> different speed grades are determined by actually testing the
> processor at temperature extremes. It's usually the high temperature
> end that has a problem with higher clock rates. Overclockers have to
> go to extremes in cooling solutions because they need to keep the part
> cooler than the max rated temperature for it to operate at the higher
> speeds plus the parts will draw more power at the higher speeds.
>
> The Atmel SAM7 parts are not speed graded and the maximum speed is
> determined by a characterization of the parts and the max frequency
> that will give a good yield. So the 55MHz rating is the frequency
> that 99.9% (or whatever their target yield is) of the processors will
> run at over the full temperature range. Some parts will be able to
> run faster. All parts should be able to run faster over a more
> restrictive temperature range. How fast depends on the individual
> parts. As the manufacturing process is refined for a particular
> component, you will usually get a higher percentage of parts that can
> run faster than the rated speeds.
>
> The two devices probably don't have the EXACT same core. They're
> probably very similar, but the different memory sizes are likely to
> cause some differences that could affect performance.
>
> Exceeding any parameters in an electronic design is like playing
> Russian Roulette. It may work on a case by case basis, but you'll
> eventually get bitten if you do it often enough.
>
> Cliff
>

--- In A..., "jeremywang2008" wrote:
>
> Thank you all, guys.
>
> Now I believe I can't do it, but I'm wondering why 7XC256 can be
> overclocked to that high and just working well.
>
> To Kris:
> I also tried your solution, set PLL out to 192MHz, then divide by 2,
> but it fails too.

You: 1) probably just had a good chip and 2) probably weren't
hitting any temperature extremes.

Processors that are speed graded often use the same core and the
different speed grades are determined by actually testing the
processor at temperature extremes. It's usually the high temperature
end that has a problem with higher clock rates. Overclockers have to
go to extremes in cooling solutions because they need to keep the part
cooler than the max rated temperature for it to operate at the higher
speeds plus the parts will draw more power at the higher speeds.

The Atmel SAM7 parts are not speed graded and the maximum speed is
determined by a characterization of the parts and the max frequency
that will give a good yield. So the 55MHz rating is the frequency
that 99.9% (or whatever their target yield is) of the processors will
run at over the full temperature range. Some parts will be able to
run faster. All parts should be able to run faster over a more
restrictive temperature range. How fast depends on the individual
parts. As the manufacturing process is refined for a particular
component, you will usually get a higher percentage of parts that can
run faster than the rated speeds.

The two devices probably don't have the EXACT same core. They're
probably very similar, but the different memory sizes are likely to
cause some differences that could affect performance.

Exceeding any parameters in an electronic design is like playing
Russian Roulette. It may work on a case by case basis, but you'll
eventually get bitten if you do it often enough.

Cliff

There are two possibilities. One is that your chip is just a really
fast chip. It happens. There is always variation in the
manufacturing process. The specs have to allow for the worst case in
several ways, process, voltage and temperature.

The other possibility is that the chip really isn't running at 96 MHz.
Maybe there is a mistake in the setup and it is running at some other
speed.

Rick

--- In A..., "jeremywang2008" wrote:
>
> Thank you all, guys.
>
> Now I believe I can't do it, but I'm wondering why 7XC256 can be
> overclocked to that high and just working well.
>
> To Kris:
> I also tried your solution, set PLL out to 192MHz, then divide by 2,
> but it fails too.
>
> Cheers,
>
> Jeremy
> --- In A..., "jeremywang2008" wrote:
> >
> > Hi,
> >
> > I'm working with a AT91SAM7XC512. It's working well under 48MHz clock,
> > now I wanna migrate to 96MHz. I checked the docs, it seems I just need
> > to change Processor Clock Prescaler from 1(PLL clock divided by 2) to
> > 0(PLL clock):
> > AT91C_BASE_PMC->PMC_MCKR = AT91C_PMC_PRES_CLK (was:
> AT91C_PMC_PRES_CLK_2);
> > while (!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MCKRDY));
> >
> > The others should be the same, coz PLL output is already 96MHz.
> > Unfortunately, it fails, and when I switch to 48MHz, it's fine.
> >
> > Thanks
> >
> > Jeremy
>

Thank you all, guys.

Now I believe I can't do it, but I'm wondering why 7XC256 can be
overclocked to that high and just working well.

To Kris:
I also tried your solution, set PLL out to 192MHz, then divide by 2,
but it fails too.

Cheers,

Jeremy
--- In A..., "jeremywang2008" wrote:
>
> Hi,
>
> I'm working with a AT91SAM7XC512. It's working well under 48MHz clock,
> now I wanna migrate to 96MHz. I checked the docs, it seems I just need
> to change Processor Clock Prescaler from 1(PLL clock divided by 2) to
> 0(PLL clock):
> AT91C_BASE_PMC->PMC_MCKR = AT91C_PMC_PRES_CLK (was:
AT91C_PMC_PRES_CLK_2);
> while (!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MCKRDY));
>
> The others should be the same, coz PLL output is already 96MHz.
> Unfortunately, it fails, and when I switch to 48MHz, it's fine.
>
> Thanks
>
> Jeremy
>

Or try the STR9 from ST if you need that kind of speed (note that it
is an ARM9 core, not ARM7).

Best,
Bogdan

On Thu, Jan 22, 2009 at 8:24 AM, 42Bastian wrote:
>> I'm working with a AT91SAM7XC512. It's working well under 48MHz clock,
>> now I wanna migrate to 96MHz. I checked the docs, it seems I just need
>
> I don't know of any ARM7TDMI-S which can run at 96MHz, maximum I saw was
> 72MHz.
>
> Read the SAM7 spec to find out the maximum core clock.
>
> --
> 42Bastian
>
> Note: SPAM-only account, direct mail to bs42@...
>

> I'm working with a AT91SAM7XC512. It's working well under 48MHz clock,
> now I wanna migrate to 96MHz. I checked the docs, it seems I just need

I don't know of any ARM7TDMI-S which can run at 96MHz, maximum I saw was
72MHz.

Read the SAM7 spec to find out the maximum core clock.
--
42Bastian

Note: SPAM-only account, direct mail to bs42@...

Naturally, that would be way too overclocked, but sometimes we can all be
surprised.
I suspect it might also equally be related to the dutycycle of the VCO
output :
CPUs & memory access (especially when pushed so far beyond their spec) need
a reasonably close to 50% clock duty to adhere to all timing params.
If your dutycycle is like - say - 25%, then some timings eg. falling->rising
edge (etc) will already be twice as short/too fast.

Give this a whirl : Set the PLL for *twice* your desired clock, and divide
it by 2 - that way you're sure there's no problems in that regard - a nice
50% duty.
Probably worth a fiddle... :-)

Best Regards,
Kris
-----Original Message-----
From: A... [mailto:A...] On Behalf Of
jeremywang2008
Sent: Thursday, 22 January 2009 8:11 AM
To: A...
Subject: [AT91SAM] Help: AT91SAM7XC512 can't work on 96 MHz

Hi,

I'm working with a AT91SAM7XC512. It's working well under 48MHz clock,
now I wanna migrate to 96MHz. I checked the docs, it seems I just need
to change Processor Clock Prescaler from 1(PLL clock divided by 2) to
0(PLL clock):
AT91C_BASE_PMC->PMC_MCKR = AT91C_PMC_PRES_CLK (was: AT91C_PMC_PRES_CLK_2);
while (!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MCKRDY));

The others should be the same, coz PLL output is already 96MHz.
Unfortunately, it fails, and when I switch to 48MHz, it's fine.

Thanks

Jeremy

This is the official page of the AT91SAM7XC512:

http://www.atmel.com/dyn/products/product_card.asp?part_idA04

And it says there:

"In industrial temperature, worse case conditions the maximum clock
frequency is 55MHz."

So why would you expect it to run at 96MHz? If you're trying to
overclock it, the jump from 55MHz to 96MHz is probably too large.

Best,
Bogdan

On Thu, Jan 22, 2009 at 12:01 AM, jeremywang2008
wrote:
> Thanks, Richard.
>
> I noticed that, but I did try the same set up on a AT91SAM7XC256
> board, it's working, while the cores of 7XC512/256 are the same.
> And I also tried different flash wait states, doesn't help. Probably,
> Master clock can't exceed 55Mhz. Anyboday has it working at higher
> than 55Mhz?
>
> --- In A..., "FreeRTOS.org Info" wrote:
>>
>> > -----Original Message-----
>> > From: A...
>> > [mailto:A...] On Behalf Of jeremywang2008
>> > Sent: 21 January 2009 21:11
>> > To: A...
>> > Subject: [AT91SAM] Help: AT91SAM7XC512 can't work on 96 MHz
>> >
>> > Hi,
>> >
>> > I'm working with a AT91SAM7XC512. It's working well under
>> > 48MHz clock, now I wanna migrate to 96MHz. I checked the
>> > docs, it seems I just need to change Processor Clock
>> > Prescaler from 1(PLL clock divided by 2) to 0(PLL clock):
>> > AT91C_BASE_PMC->PMC_MCKR = AT91C_PMC_PRES_CLK (was:
>> > AT91C_PMC_PRES_CLK_2); while (!(AT91C_BASE_PMC->PMC_SR &
>> > AT91C_PMC_MCKRDY));
>> >
>> > The others should be the same, coz PLL output is already 96MHz.
>> > Unfortunately, it fails, and when I switch to 48MHz, it's fine.
>> >
>>
>> According to
> http://www.atmel.com/dyn/resources/prod_documents/6209s.pdf the
>> core runs at 55MHz max. If it does run faster then maybe you need
> to adjust
>> the flash access parameters.
>>
>> Regards,
>> Richard.
>>
>> + http://www.FreeRTOS.org
>> Designed for Microcontrollers. More than 7000 downloads per month.
>>
>> +
> http://www.freertos.org/Documentation/FreeRTOS-documentation-and-book.html
>> New FreeRTOS eBook.
>>

Thanks, Richard.

I noticed that, but I did try the same set up on a AT91SAM7XC256
board, it's working, while the cores of 7XC512/256 are the same.
And I also tried different flash wait states, doesn't help. Probably,
Master clock can't exceed 55Mhz. Anyboday has it working at higher
than 55Mhz?

--- In A..., "FreeRTOS.org Info" wrote:
>
> > -----Original Message-----
> > From: A...
> > [mailto:A...] On Behalf Of jeremywang2008
> > Sent: 21 January 2009 21:11
> > To: A...
> > Subject: [AT91SAM] Help: AT91SAM7XC512 can't work on 96 MHz
> >
> > Hi,
> >
> > I'm working with a AT91SAM7XC512. It's working well under
> > 48MHz clock, now I wanna migrate to 96MHz. I checked the
> > docs, it seems I just need to change Processor Clock
> > Prescaler from 1(PLL clock divided by 2) to 0(PLL clock):
> > AT91C_BASE_PMC->PMC_MCKR = AT91C_PMC_PRES_CLK (was:
> > AT91C_PMC_PRES_CLK_2); while (!(AT91C_BASE_PMC->PMC_SR &
> > AT91C_PMC_MCKRDY));
> >
> > The others should be the same, coz PLL output is already 96MHz.
> > Unfortunately, it fails, and when I switch to 48MHz, it's fine.
> > According to
http://www.atmel.com/dyn/resources/prod_documents/6209s.pdf the
> core runs at 55MHz max. If it does run faster then maybe you need
to adjust
> the flash access parameters.
>
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org
> Designed for Microcontrollers. More than 7000 downloads per month.
>
> +
http://www.freertos.org/Documentation/FreeRTOS-documentation-and-book.html
> New FreeRTOS eBook.
>