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
AT91SAM7S256
Started by ●September 16, 2008
Reply by ●September 16, 20082008-09-16
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
>
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
>
Reply by ●September 17, 20082008-09-17
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
>
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
>
Reply by ●September 17, 20082008-09-17
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
>
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
>
Reply by ●September 17, 20082008-09-17
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
>
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
>
Reply by ●September 17, 20082008-09-17
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
>
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
>
Reply by ●September 17, 20082008-09-17
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
>
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
>
Reply by ●September 17, 20082008-09-17
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.
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.
Reply by ●October 17, 20082008-10-17
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
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
Reply by ●October 17, 20082008-10-17
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
>
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
>
