That fixed my problem, also! I think the debugger changes the MCLK to
the fast clock, which would explain why I could run in the first place
at 55 MHz only while debugging. So you're right - you have to
manually set to the slow clock before doing that configuration. This
makes debugging MUCH easier!
--- In A..., "techguy2000" wrote:
> I hit the same problem with the debugger. Debuggers tend to step in
> and set stuff up, especially if they're programming flash, and may set
> things up in bad ways for some of the other initializations that your
> code is attempting to do once the debugger releases control.
>
> The fix is to make sure that slow clock is the selected clock before
> doing any of the initializations that expect slow clock to be active.
> I do this prior to setting up the flash wait states:
>
> /* insure we're on the slow clock */
> pPMC->PMC_MCKR &= ~0x03;
> while(!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));
>
> This solved the debugger problem for IAR/Jlink.
>
> -Cliff
>
> --- In A..., "ryan100patterson"
> wrote:
> >
> > Cliff,
> >
> > You're a genius! I've been trying to figure out this problem all
> > year, and eventually resorted to running at only 50 MHz on most of my
> > projects. I've gone through the user's manual many times and never
> > caught this...
> >
> > So I've implemented the code as you suggested, and it runs on the
> > slowest silicon AT91SAMs that I have.
> >
> > However, I've found that this code change causes my processor to lock
> > up when debugging. The debugger gets stuck on:
> >
> > while (!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));
> >
> > If I watch pPMC-PMC_SR, I see that it has the value 5. However, if I
> > step through this section of code, it has the value 13, and therefore
> > succeeds. Does anybody have any idea why the MCKRDY bit wouldn't get
> > set in PMC_SR while running in the debugger? Also, if I program the
> > device and let it run without the debugger attached, it works just
fine.
> >
> > Thanks!
> >
> > Best Regards,
> > Ryan
> >
> >
> >
> > --- In A..., "techguy2000" wrote:
> > >
> > >
> > > I may have found what may be the "real" problem. It's actually in
> > > the user manual, but was implemented incorrectly in the example code
> > > we were working from (which I think was originally from Atmel).
> > >
> > > When writing to the PMC_MCKR register, you update one field, wait
> > > for MCKRDY, then update the other field and wait for MCKRDY again.
> > > Which field you write first depends on which clock is being
selected.
> > > It's in the "Programming Sequence" section for the PMC
controller in
> > > the manual.
> > >
> > > Doing that, with all other delays and other extraneous code
removed
> > > from the init routine I'm using changed a device that would fail
> > > consistently using the single write method and work consistently
doing
> > > two writes.
> > >
> > > So for me going from slow clock to PLL clock:
> > >
> > > pPMC->PMC_MCKR = AT91C_PMC_PRES_CLK_2 | AT91C_PMC_CSS_SLOW_CLK;
> > > while (!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));
> > > pPMC->PMC_MCKR = AT91C_PMC_PRES_CLK_2 | AT91C_PMC_CSS_PLL_CLK;
> > > while (!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));
> > >
> > > Slow clock was already selected when entering this code.
> > >
> > > Is anyone that is seeing this problem while doing the double write
> > > to the PMC_MCKR register?
> > >
> > > Cliff
>

I hit the same problem with the debugger. Debuggers tend to step in
and set stuff up, especially if they're programming flash, and may set
things up in bad ways for some of the other initializations that your
code is attempting to do once the debugger releases control.

The fix is to make sure that slow clock is the selected clock before
doing any of the initializations that expect slow clock to be active.
I do this prior to setting up the flash wait states:

/* insure we're on the slow clock */
pPMC->PMC_MCKR &= ~0x03;
while(!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));

This solved the debugger problem for IAR/Jlink.

-Cliff

--- In A..., "ryan100patterson"
wrote:
>
> Cliff,
>
> You're a genius! I've been trying to figure out this problem all
> year, and eventually resorted to running at only 50 MHz on most of my
> projects. I've gone through the user's manual many times and never
> caught this...
>
> So I've implemented the code as you suggested, and it runs on the
> slowest silicon AT91SAMs that I have.
>
> However, I've found that this code change causes my processor to lock
> up when debugging. The debugger gets stuck on:
>
> while (!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));
>
> If I watch pPMC-PMC_SR, I see that it has the value 5. However, if I
> step through this section of code, it has the value 13, and therefore
> succeeds. Does anybody have any idea why the MCKRDY bit wouldn't get
> set in PMC_SR while running in the debugger? Also, if I program the
> device and let it run without the debugger attached, it works just fine.
>
> Thanks!
>
> Best Regards,
> Ryan
>
> --- In A..., "techguy2000" wrote:
> >
> >
> > I may have found what may be the "real" problem. It's actually in
> > the user manual, but was implemented incorrectly in the example code
> > we were working from (which I think was originally from Atmel).
> >
> > When writing to the PMC_MCKR register, you update one field, wait
> > for MCKRDY, then update the other field and wait for MCKRDY again.
> > Which field you write first depends on which clock is being selected.
> > It's in the "Programming Sequence" section for the PMC controller in
> > the manual.
> >
> > Doing that, with all other delays and other extraneous code removed
> > from the init routine I'm using changed a device that would fail
> > consistently using the single write method and work consistently doing
> > two writes.
> >
> > So for me going from slow clock to PLL clock:
> >
> > pPMC->PMC_MCKR = AT91C_PMC_PRES_CLK_2 | AT91C_PMC_CSS_SLOW_CLK;
> > while (!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));
> > pPMC->PMC_MCKR = AT91C_PMC_PRES_CLK_2 | AT91C_PMC_CSS_PLL_CLK;
> > while (!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));
> >
> > Slow clock was already selected when entering this code.
> >
> > Is anyone that is seeing this problem while doing the double write
> > to the PMC_MCKR register?
> >
> > Cliff
>

Cliff,

You're a genius! I've been trying to figure out this problem all
year, and eventually resorted to running at only 50 MHz on most of my
projects. I've gone through the user's manual many times and never
caught this...

So I've implemented the code as you suggested, and it runs on the
slowest silicon AT91SAMs that I have.

However, I've found that this code change causes my processor to lock
up when debugging. The debugger gets stuck on:

while (!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));

If I watch pPMC-PMC_SR, I see that it has the value 5. However, if I
step through this section of code, it has the value 13, and therefore
succeeds. Does anybody have any idea why the MCKRDY bit wouldn't get
set in PMC_SR while running in the debugger? Also, if I program the
device and let it run without the debugger attached, it works just fine.

Thanks!

Best Regards,
Ryan

--- In A..., "techguy2000" wrote:
> I may have found what may be the "real" problem. It's actually in
> the user manual, but was implemented incorrectly in the example code
> we were working from (which I think was originally from Atmel).
>
> When writing to the PMC_MCKR register, you update one field, wait
> for MCKRDY, then update the other field and wait for MCKRDY again.
> Which field you write first depends on which clock is being selected.
> It's in the "Programming Sequence" section for the PMC controller in
> the manual.
>
> Doing that, with all other delays and other extraneous code removed
> from the init routine I'm using changed a device that would fail
> consistently using the single write method and work consistently doing
> two writes.
>
> So for me going from slow clock to PLL clock:
>
> pPMC->PMC_MCKR = AT91C_PMC_PRES_CLK_2 | AT91C_PMC_CSS_SLOW_CLK;
> while (!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));
> pPMC->PMC_MCKR = AT91C_PMC_PRES_CLK_2 | AT91C_PMC_CSS_PLL_CLK;
> while (!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));
>
> Slow clock was already selected when entering this code.
>
> Is anyone that is seeing this problem while doing the double write
> to the PMC_MCKR register?
>
> Cliff

I've used their excel spreadsheet to calculate the PLL filter values
and the components we're using fall in the middle of the "good" range.
But then again, maybe those parameters have changed for Rev B.

I don't care much for that spreadsheet, though. You need to enter a
target Q for the circuit and the only recommendation I've seen from an
Atmel engineer on acceptable Q value is "as high as possible" with no
other guidance as to an actual value, so you could take "as high as
possible" as the maximum number the program will accept. Of course,
that won't work, so you're stuck with a guess as to a good value for Q.

Atmel really should have had a utility that would take in the
crystal and PLL parameters and output ideal values for the RC
components rather than the trial and error, poorly defined,
spreadsheet. It's better than nothing, I guess.

I have emailed Atmel support about the problem. In the past I've
always gotten a response, but sometimes it takes a while.

Cliff

--- In A..., "Eric Pasquier" wrote:
>
> Dear Cliff,
>
> Did you check with Atmel your initialization PLL parameters with
your actual crystal characteristics and R/C PLL Filter ?
> (I know that it's working with the previous revision but may be
something is at the limit ?)
>
> I don't know if Atmel Engineers are monitoring this list; may be you
can post your initialization sequence and HW characteristics here.
>
> Eric.

I may have found what may be the "real" problem. It's actually in
the user manual, but was implemented incorrectly in the example code
we were working from (which I think was originally from Atmel).

When writing to the PMC_MCKR register, you update one field, wait
for MCKRDY, then update the other field and wait for MCKRDY again.
Which field you write first depends on which clock is being selected.
It's in the "Programming Sequence" section for the PMC controller in
the manual.

Doing that, with all other delays and other extraneous code removed
from the init routine I'm using changed a device that would fail
consistently using the single write method and work consistently doing
two writes.

So for me going from slow clock to PLL clock:

pPMC->PMC_MCKR = AT91C_PMC_PRES_CLK_2 | AT91C_PMC_CSS_SLOW_CLK;
while (!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));
pPMC->PMC_MCKR = AT91C_PMC_PRES_CLK_2 | AT91C_PMC_CSS_PLL_CLK;
while (!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));

Slow clock was already selected when entering this code.

Is anyone that is seeing this problem while doing the double write
to the PMC_MCKR register?

Cliff

--- In A..., "John Eigelaar" wrote:
>
> We have experienced the same problems. Eventually I could pin point two
> things:
>
>
>
> 1. After a soft reset, the internal reset circuitry seems to
release
> the reset line before the MCK is stable.
>
> The fix for this is to wait for MCKRDY bit to be set before any clock
> configuration is done. We now wait for MCKRDY
>
> and then force a switch to the slow clock just to be sure we always
start
> from the same point after soft or poweron reset.
>
> 2. The MOSCCOUNT value suggested by Atmel in their sample
startup code
> has changed from 6 in the original version 3 years ago
>
> to 64 in the latest version. This might suggest that a change in
process has
> made the main oscillator to take longer to start up.
>
>
>
> I found the situation a bit disgusting as no Atmel engineer or FAE
relayed
> this information to their customers prior to shipping these parts
that needs
> special treatment. Also beware we had the same problem with SAM7S512,
> SAM7X256 and SAM7X512
>
>
>
> Happy Hacking
>
> John Eigelaar
>
>
>
>
>
>
>
>
>
> From: A... [mailto:A...] On
Behalf Of
> techguy2000
> Sent: 17 September 2008 03:56 AM
> To: A...
> Subject: [AT91SAM] Re: AT91SAM7S256
>
>
> This might be the same problem I asked about a couple of days ago.
>
> The problem I have appears to have something to do with switching
> from slow clock to PLL clock during the device initialization. I've
> seen two symptoms, one is a data abort when trying to run the IAR
> _seginit C initialization routine, and the other is the PIT doesn't
> work right after initialization. There are errata on the Rev A parts
> around switching clocks, but that's generally from a faster to a
> slower clock and I tried the remedies for the errata and it didn't
> make any difference.
>
> The fix that worked for me is putting a delay between waiting for
> the PLL LOCK bit to be asserted after programming the PLL and making
> the PLL clock the master clock. It's a temporary fix until the
> problem is understood better. I may have just gotten lucky this
> worked and the real problem requires another fix.
>
> I've also found the problem seems to get worse when the part is hot
> and better when it's cold. I can't say if that's generally true, but
> it was true on the two boards I've been debugging the problem with.
>
> Try adding the delay and let me know how it works for you.
>
> Cliff
>
> --- In A... ,
"Jerry
> West" wrote:
> >
> > Have built 650 units using the AT91SAM7S256AU Rev A chip. Next build
> used
> > Rev B chip Ocaisoinal problems are encountered with starting the
> processor
> > from power up. The application is running under Keil RTX. No changes
> make to
> > code between Rev A and Rev B build. Using the JTAG to investigate
> shows the
> > processor to be hung initializing the RTX. The main function is
> called which
> > calls the os_sys_init(init) to start the OS. The OS does not always
> return
> > control the funciton named init. When control is not returned, the
> processor
> > runs to a point where the SWI function in the OS is called and
execution
> > transfers back to the startup code. This loop operates indefinately
> until
> > power is cycled.
> >
> >
> >
> > The frequency of this event varies from about one in ten startups to
> one in
> > fifty.
> >
> >
> >
> > Has any one seen a similar problem? What was the fix?
> >
> >
> >
> > Kindest Regards,
> >
> > Jerry West
> >
> > Jerry West, LLC
> >
> > 610 Clinton St.
> >
> > Ovilla, TX 75154-5577
> >
> > 469 231 2784 Cell
> >
> > 972 515 8668 Ofc
> >
> > 972 692 5937 Fax
>

Thanks for the inforation.

Jerry

From: A... [mailto:A...] On Behalf Of
John Eigelaar
Sent: Wednesday, September 17, 2008 3:30 AM
To: A...
Subject: RE: [AT91SAM] Re: AT91SAM7S256

We have experienced the same problems. Eventually I could pin point two
things:

1. After a soft reset, the internal reset circuitry seems to release
the reset line before the MCK is stable.

The fix for this is to wait for MCKRDY bit to be set before any clock
configuration is done. We now wait for MCKRDY

and then force a switch to the slow clock just to be sure we always start
from the same point after soft or poweron reset.

2. The MOSCCOUNT value suggested by Atmel in their sample startup code
has changed from 6 in the original version 3 years ago

to 64 in the latest version. This might suggest that a change in process has
made the main oscillator to take longer to start up.

I found the situation a bit disgusting as no Atmel engineer or FAE relayed
this information to their customers prior to shipping these parts that needs
special treatment. Also beware we had the same problem with SAM7S512,
SAM7X256 and SAM7X512

Happy Hacking

John Eigelaar

From: A... [mailto:A...] On Behalf Of
techguy2000
Sent: 17 September 2008 03:56 AM
To: A...
Subject: [AT91SAM] Re: AT91SAM7S256

This might be the same problem I asked about a couple of days ago.

The problem I have appears to have something to do with switching
from slow clock to PLL clock during the device initialization. I've
seen two symptoms, one is a data abort when trying to run the IAR
_seginit C initialization routine, and the other is the PIT doesn't
work right after initialization. There are errata on the Rev A parts
around switching clocks, but that's generally from a faster to a
slower clock and I tried the remedies for the errata and it didn't
make any difference.

The fix that worked for me is putting a delay between waiting for
the PLL LOCK bit to be asserted after programming the PLL and making
the PLL clock the master clock. It's a temporary fix until the
problem is understood better. I may have just gotten lucky this
worked and the real problem requires another fix.

I've also found the problem seems to get worse when the part is hot
and better when it's cold. I can't say if that's generally true, but
it was true on the two boards I've been debugging the problem with.

Try adding the delay and let me know how it works for you.

Cliff

--- In A... , "Jerry
West" wrote:
>
> Have built 650 units using the AT91SAM7S256AU Rev A chip. Next build
used
> Rev B chip Ocaisoinal problems are encountered with starting the
processor
> from power up. The application is running under Keil RTX. No changes
make to
> code between Rev A and Rev B build. Using the JTAG to investigate
shows the
> processor to be hung initializing the RTX. The main function is
called which
> calls the os_sys_init(init) to start the OS. The OS does not always
return
> control the funciton named init. When control is not returned, the
processor
> runs to a point where the SWI function in the OS is called and execution
> transfers back to the startup code. This loop operates indefinately
until
> power is cycled.
>
> The frequency of this event varies from about one in ten startups to
one in
> fifty.
>
> Has any one seen a similar problem? What was the fix?
>
> Kindest Regards,
>
> Jerry West
>
> Jerry West, LLC
>
> 610 Clinton St.
>
> Ovilla, TX 75154-5577
>
> 469 231 2784 Cell
>
> 972 515 8668 Ofc
>
> 972 692 5937 Fax
>

We have experienced the same problems. Eventually I could pin point two
things:

1. After a soft reset, the internal reset circuitry seems to release
the reset line before the MCK is stable.

The fix for this is to wait for MCKRDY bit to be set before any clock
configuration is done. We now wait for MCKRDY

and then force a switch to the slow clock just to be sure we always start
from the same point after soft or poweron reset.

2. The MOSCCOUNT value suggested by Atmel in their sample startup code
has changed from 6 in the original version 3 years ago

to 64 in the latest version. This might suggest that a change in process has
made the main oscillator to take longer to start up.

I found the situation a bit disgusting as no Atmel engineer or FAE relayed
this information to their customers prior to shipping these parts that needs
special treatment. Also beware we had the same problem with SAM7S512,
SAM7X256 and SAM7X512

Happy Hacking

John Eigelaar

From: A... [mailto:A...] On Behalf Of
techguy2000
Sent: 17 September 2008 03:56 AM
To: A...
Subject: [AT91SAM] Re: AT91SAM7S256

This might be the same problem I asked about a couple of days ago.

The problem I have appears to have something to do with switching
from slow clock to PLL clock during the device initialization. I've
seen two symptoms, one is a data abort when trying to run the IAR
_seginit C initialization routine, and the other is the PIT doesn't
work right after initialization. There are errata on the Rev A parts
around switching clocks, but that's generally from a faster to a
slower clock and I tried the remedies for the errata and it didn't
make any difference.

The fix that worked for me is putting a delay between waiting for
the PLL LOCK bit to be asserted after programming the PLL and making
the PLL clock the master clock. It's a temporary fix until the
problem is understood better. I may have just gotten lucky this
worked and the real problem requires another fix.

I've also found the problem seems to get worse when the part is hot
and better when it's cold. I can't say if that's generally true, but
it was true on the two boards I've been debugging the problem with.

Try adding the delay and let me know how it works for you.

Cliff

--- In A... , "Jerry
West" wrote:
>
> Have built 650 units using the AT91SAM7S256AU Rev A chip. Next build
used
> Rev B chip Ocaisoinal problems are encountered with starting the
processor
> from power up. The application is running under Keil RTX. No changes
make to
> code between Rev A and Rev B build. Using the JTAG to investigate
shows the
> processor to be hung initializing the RTX. The main function is
called which
> calls the os_sys_init(init) to start the OS. The OS does not always
return
> control the funciton named init. When control is not returned, the
processor
> runs to a point where the SWI function in the OS is called and execution
> transfers back to the startup code. This loop operates indefinately
until
> power is cycled.
>
> The frequency of this event varies from about one in ten startups to
one in
> fifty.
>
> Has any one seen a similar problem? What was the fix?
>
> Kindest Regards,
>
> Jerry West
>
> Jerry West, LLC
>
> 610 Clinton St.
>
> Ovilla, TX 75154-5577
>
> 469 231 2784 Cell
>
> 972 515 8668 Ofc
>
> 972 692 5937 Fax
>

Dear Cliff,

Did you check with Atmel your initialization PLL parameters with your actual crystal characteristics and R/C PLL Filter ?
(I know that it's working with the previous revision but may be something is at the limit ?)

I don't know if Atmel Engineers are monitoring this list; may be you can post your initialization sequence and HW characteristics here.

Eric.

----- Original Message -----
From: techguy2000
To: A...
Sent: Wednesday, September 17, 2008 3:56 AM
Subject: [AT91SAM] Re: AT91SAM7S256

This might be the same problem I asked about a couple of days ago.

The problem I have appears to have something to do with switching
from slow clock to PLL clock during the device initialization. I've
seen two symptoms, one is a data abort when trying to run the IAR
_seginit C initialization routine, and the other is the PIT doesn't
work right after initialization. There are errata on the Rev A parts
around switching clocks, but that's generally from a faster to a
slower clock and I tried the remedies for the errata and it didn't
make any difference.

The fix that worked for me is putting a delay between waiting for
the PLL LOCK bit to be asserted after programming the PLL and making
the PLL clock the master clock. It's a temporary fix until the
problem is understood better. I may have just gotten lucky this
worked and the real problem requires another fix.

I've also found the problem seems to get worse when the part is hot
and better when it's cold. I can't say if that's generally true, but
it was true on the two boards I've been debugging the problem with.

Try adding the delay and let me know how it works for you.

Cliff

--- In A..., "Jerry West" wrote:
>
> Have built 650 units using the AT91SAM7S256AU Rev A chip. Next build
used
> Rev B chip Ocaisoinal problems are encountered with starting the
processor
> from power up. The application is running under Keil RTX. No changes
make to
> code between Rev A and Rev B build. Using the JTAG to investigate
shows the
> processor to be hung initializing the RTX. The main function is
called which
> calls the os_sys_init(init) to start the OS. The OS does not always
return
> control the funciton named init. When control is not returned, the
processor
> runs to a point where the SWI function in the OS is called and execution
> transfers back to the startup code. This loop operates indefinately
until
> power is cycled.
>
>
>
> The frequency of this event varies from about one in ten startups to
one in
> fifty.
>
>
>
> Has any one seen a similar problem? What was the fix?
>
>
>
> Kindest Regards,
>
> Jerry West
>
> Jerry West, LLC
>
> 610 Clinton St.
>
> Ovilla, TX 75154-5577
>
> 469 231 2784 Cell
>
> 972 515 8668 Ofc
>
> 972 692 5937 Fax
>

Thanks,

I will give that a try. That happens in the Keil RTX code, but I have source
and can do it.

Jerry

From: A... [mailto:A...] On Behalf Of
techguy2000
Sent: Tuesday, September 16, 2008 8:56 PM
To: A...
Subject: [AT91SAM] Re: AT91SAM7S256

This might be the same problem I asked about a couple of days ago.

The problem I have appears to have something to do with switching
from slow clock to PLL clock during the device initialization. I've
seen two symptoms, one is a data abort when trying to run the IAR
_seginit C initialization routine, and the other is the PIT doesn't
work right after initialization. There are errata on the Rev A parts
around switching clocks, but that's generally from a faster to a
slower clock and I tried the remedies for the errata and it didn't
make any difference.

The fix that worked for me is putting a delay between waiting for
the PLL LOCK bit to be asserted after programming the PLL and making
the PLL clock the master clock. It's a temporary fix until the
problem is understood better. I may have just gotten lucky this
worked and the real problem requires another fix.

I've also found the problem seems to get worse when the part is hot
and better when it's cold. I can't say if that's generally true, but
it was true on the two boards I've been debugging the problem with.

Try adding the delay and let me know how it works for you.

Cliff

--- In A... , "Jerry
West" wrote:
>
> Have built 650 units using the AT91SAM7S256AU Rev A chip. Next build
used
> Rev B chip Ocaisoinal problems are encountered with starting the
processor
> from power up. The application is running under Keil RTX. No changes
make to
> code between Rev A and Rev B build. Using the JTAG to investigate
shows the
> processor to be hung initializing the RTX. The main function is
called which
> calls the os_sys_init(init) to start the OS. The OS does not always
return
> control the funciton named init. When control is not returned, the
processor
> runs to a point where the SWI function in the OS is called and execution
> transfers back to the startup code. This loop operates indefinately
until
> power is cycled.
>
> The frequency of this event varies from about one in ten startups to
one in
> fifty.
>
> Has any one seen a similar problem? What was the fix?
>
> Kindest Regards,
>
> Jerry West
>
> Jerry West, LLC
>
> 610 Clinton St.
>
> Ovilla, TX 75154-5577
>
> 469 231 2784 Cell
>
> 972 515 8668 Ofc
>
> 972 692 5937 Fax
>

This might be the same problem I asked about a couple of days ago.

The problem I have appears to have something to do with switching
from slow clock to PLL clock during the device initialization. I've
seen two symptoms, one is a data abort when trying to run the IAR
_seginit C initialization routine, and the other is the PIT doesn't
work right after initialization. There are errata on the Rev A parts
around switching clocks, but that's generally from a faster to a
slower clock and I tried the remedies for the errata and it didn't
make any difference.

The fix that worked for me is putting a delay between waiting for
the PLL LOCK bit to be asserted after programming the PLL and making
the PLL clock the master clock. It's a temporary fix until the
problem is understood better. I may have just gotten lucky this
worked and the real problem requires another fix.

I've also found the problem seems to get worse when the part is hot
and better when it's cold. I can't say if that's generally true, but
it was true on the two boards I've been debugging the problem with.

Try adding the delay and let me know how it works for you.

Cliff

--- In A..., "Jerry West" wrote:
>
> Have built 650 units using the AT91SAM7S256AU Rev A chip. Next build
used
> Rev B chip Ocaisoinal problems are encountered with starting the
processor
> from power up. The application is running under Keil RTX. No changes
make to
> code between Rev A and Rev B build. Using the JTAG to investigate
shows the
> processor to be hung initializing the RTX. The main function is
called which
> calls the os_sys_init(init) to start the OS. The OS does not always
return
> control the funciton named init. When control is not returned, the
processor
> runs to a point where the SWI function in the OS is called and execution
> transfers back to the startup code. This loop operates indefinately
until
> power is cycled.
>
>
>
> The frequency of this event varies from about one in ten startups to
one in
> fifty.
>
>
>
> Has any one seen a similar problem? What was the fix?
>
>
>
> Kindest Regards,
>
> Jerry West
>
> Jerry West, LLC
>
> 610 Clinton St.
>
> Ovilla, TX 75154-5577
>
> 469 231 2784 Cell
>
> 972 515 8668 Ofc
>
> 972 692 5937 Fax
>