My memory is terrible, but I think I've seen and fixed this problem before
(on a SAM9 part), and that the problem isn't the chip but the way the
compiler / linker is working. I assign my startup vectors into a separate
section, as per the following snippet

.section .vectors,"ax"
// It is compiled in 32 bit (ARM) mode
.code 32

//
// The initial vector table
// The secondary jump table will be re-written later
//
_vectors:
ldr pc, ResetAddr // Reset vector
ldr pc, UndefAddr // Undefined instruction vector
ldr pc, SWIAddr // Software interrupt vector
ldr pc, PAbortAddr // Prefetch abort vector
ldr pc, DAbortAddr // Data abort vector
ldr pc, ReservedAddr // Reserved vector
ldr pc, IRQAddr // IRQ interrupt vector
ldr pc, FIQAddr // FIQ interrupt vector
...

Then in the linker file I have the following snippet

SECTIONS
{
/* startup needs to be first so that the vectors go in the correct place.
* If the startup sections are in text, which is the logical place for
* them, GCC will insert the ARM/THUMB interworking stub before them,
which
* doesn't work. Declaring a separate section fixes this problem.
*/
.startup :
{
*(.default_vectors);
. = ALIGN(4);
*(.copyright);
. = ALIGN(4);
} > PSRAM

.text :
{
*(.init);
. = ALIGN(4);
*(.text.fastcode);
. = ALIGN(4);
*(.text);

...
and I think that will solve your problem.

Steve

On Thu, Sep 17, 2009 at 10:20 AM, Ralph Hempel wrote:

> Bill Knight wrote:
> > All
> > OK gang here is the update. I am using GCC 4.3.3 w/ Binutils 2.19.1
> > from the YAGARTO tools. In my code, I had inadvertently included a
> > float constant and assigned its value to a variable. The compiler
> > included a tiny bit of code in a new .text.stub section and the linker
> > placed it at the base for flash RIGHT WHERE THE STARTUP VECTORS ARE
> > SUPPOSE TO GO and displaced the startup vectors by 16 bytes.
>
> Bill, can you go back to an older binutils?
>
> I think I had the same problem with 2.19 as you are having, and
> I ended up going back to 2.17 or 2.18 - I'm not in front of my
> normal development machine right now...
>
> Ralph
>
>
>

--
******************************
Steve Manion
S...@Metrozet.com
(626) 507-8025
(626) 437-6905

WWW.METROZET.COM
******************************

Bill Knight wrote:
> All
> OK gang here is the update. I am using GCC 4.3.3 w/ Binutils 2.19.1
> from the YAGARTO tools. In my code, I had inadvertently included a
> float constant and assigned its value to a variable. The compiler
> included a tiny bit of code in a new .text.stub section and the linker
> placed it at the base for flash RIGHT WHERE THE STARTUP VECTORS ARE
> SUPPOSE TO GO and displaced the startup vectors by 16 bytes.

Bill, can you go back to an older binutils?

I think I had the same problem with 2.19 as you are having, and
I ended up going back to 2.17 or 2.18 - I'm not in front of my
normal development machine right now...

Ralph

All
OK gang here is the update. I am using GCC 4.3.3 w/ Binutils 2.19.1
from the YAGARTO tools. In my code, I had inadvertently included a
float constant and assigned its value to a variable. The compiler
included a tiny bit of code in a new .text.stub section and the linker
placed it at the base for flash RIGHT WHERE THE STARTUP VECTORS ARE
SUPPOSE TO GO and displaced the startup vectors by 16 bytes. The new
code at the base of flash used mostly register values. The 16 byte
displacement of the vectors moved the reset vector to the address where
the data abort vector would normally reside. Anyway, when the processor
started up, it began executing the linker stub code at the base of flash
and if the uninitialized register values were such that a data abort
exception was caused, the code actually executed the reset code and the
system came up. If the register values were such that there was no data
abort, the processor went out into the weeds. On rev A parts on power
up, the uninitialized values of the registers tended to cause a data
abort and the system came up. On rev B parts, the opposite happened and
the processor hung. So to put it bluntly, the problem I have been
fighting was not a rev B problem. The rev A parts just tended to mask
it. A couple of quick ways to see if this is the problem you may be
experiencing are 1) check the .MAP file to see what is a 0x00100000 and
2) look at the binary output file and confirm the vector code is at the
beginning.
So far I have not found a reliable way to get the linker stubs in
section .text.stub to be placed anywhere else but at the start of ROM.
There have been suggestions about putting the crt0.s code in its own
section and placing that before the .text section in the linker control
file but my attempts to get that to work have so far failed. My work
around so far has simply been to change the float constant back to the
integer constant it was suppose to be in the first place which removes
the need for the .text.stub section altogether. I have also downloaded
the latest version of the YAGARTO tools (GCC 4.4.1 & Binutils 2.19.1)
and will see if that corrects the underlying problem.

Regards
-Bill Knight
R O SoftWare
Bill Knight wrote:
> Jerry
> Thanks for the update, though the news isn't encouraging. It just
> bugs me that the SAM-BA boot loader seems to come up reliably on the USB
> connection but I cannot get the same results. I haven't replaced the
> rev B parts on the new board with rev A's in oder to compare results but
> seeing as the design is almost a cut-and-paste of a working design
> (using rev A parts), I expect the rev A parts would work as they are
> suppose to.
>
> Again, sure wish I could get my eyes on the source of at least the
> startup portion of the SAM-BA boot loader code that is in the part.
>
> We have a build pending that would use up to 3,200 SAM7S256's, but
> not until I can get this resolved.
>
> Anyway Jerry, thanks for the info. I'll keep you and the group
> posted about any successes I can manage.
>
> -Bill Knight
> R O SoftWare
>
> Jerry West wrote:
>> I have been building products with the AT91SAM7S256 for 3 years. I had
>> no problems with the first 1000 units which were constructed with Rev A
>> parts. The next 1000 were built with Rev B parts and about 80% of the
>> units would intermittently halt on power up with a data abort. I could
>> not find a reason and bought Rev A parts on the surplus market. The
>> boards all worked.
>>
>> I am now facing the problem again as no Rev A parts are located. I used
>> a 20.48 MHz crystal and had the PLL double the CPU clock to 40.96 MHz.
>>
>> I have just redesigned the PCB to use an external oscillator since I was
>> cheating on the upper frequency limit of 20.0 MHz at 20.48 MHz. I have
>> not started the debug effort yet but will be in it next week. I do wish
>> Atmel would tell us what they changed.
>>
>> Jerry
>>
>>
>>
>> *From:* A... [mailto:A...] *On
>> Behalf Of *Bill Knight
>> *Sent:* Wednesday, September 02, 2009 3:15 PM
>> *To:* A...
>> *Subject:* Re: [AT91SAM] Yet another problem with Rev B AT91SAM7's
>>
>>
>> techguy2000 wrote:
>> > We've been using the SAM7 chips for several years with very few
>> > problems, but Atmel seems to have introduced problems with the Rev B
>> > devices. At least that seems to be where the troubles started.
>> >
>> > We've already hit the "must reset SPI port twice" unpublished
>> > errata. In talking to Atmel support, they were aware of the problem,
>> > but hadn't published as an errata. Nice product support.
>> >
>> > Now we're seeing a problem that I think has to do with the PLL.
>> > We've recently had a noticeable percentage of devices that weren't
>> > working or were working intermittently. I've seen a couple of
>> > symptoms: Random data aborts during early initialization and finding
>> > that the PIT timer wasn't counting and its registers indicating it
>> > hadn't been programmed, even though I'm sure it was.
>> >
>> > Putting a short delay after the wait for the PLL lock bit, but
>> > before making the PLLCLK/2 the master clock seems to fix the problem,
>> > indicating that maybe the PLL hadn't really settled down when the lock
>> > bit indicates it has.
>> >
>> > Anyone else seeing this problem?
>> >
>> > Cliff
>>
>> YES! I just started debugging a board with a number of SAM7S256 rev B
>> parts all connected via on-board USB hub chips. The SAM-BA boot loader
>> comes up fine and the parts can be programmed. The programmed code
>> usually runs properly after pressing the on-board reset buttons.
>> However, if the power is removed and reapplied the majority of the
>> processors typically do not start up their oscillators. The design is
>> one that has been running just fine w/ one processor per board (rev A
>> parts). This version puts multiple processors on the same board and it
>> is not at all reliable.
>>
>> I tried your suggestion of putting in a short delay and it does not seem
>> to help. I even have tried short delays between most of the
>> initialization operations without success. Anyone have any additional
>> suggestions?
>>
>> Like I said, what bugs me is that the SAM-BA boot loader seems to come
>> up fine. Anyone know if the source code for is is available somewhere?
>>
>> Regards
>> -Bill Knight
>> R O SoftWare

--- In A..., "Jerry West" wrote:
>
> IN the document AT91SAM7S256-08 page 553 it is spec'd as a minimum rise
> time.
>
>
I read that spec as a minimum of 6 V/ms, so faster rising as allowed. That means there is _maximum_ risetime.

And do not take that spec lightly. Ramping the supply too slow can completely hang the SAM7, requiring a complete power cycle to restart (reset will not work). This als means you have to be carefull with switching regulators with large output caps, they can ramp up too slow. I now mostly use a 4V voltage monitor that enables my 3V3 LDO. This ensures a nice, clean and fast ramp up of my 3V3 supply.

--
Stef

IN the document AT91SAM7S256-08 page 553 it is spec'd as a minimum rise
time.

Jw

From: A... [mailto:A...] On Behalf Of
gnuarm
Sent: Wednesday, September 02, 2009 4:49 PM
To: A...
Subject: [AT91SAM] Re: Yet another problem with Rev B AT91SAM7's

Hmmmm... I read that item and realized it was not very well described. How
do you know if that is a max or a min risetime? I don't have a lot of
experience with this sort of "constraint". The only other one I remember
encountering was on the Spartan 2 devices from Xilinx. The Vdd had to rise
monotonically and I think it had a *max* rate of rise. You might want to
contact Atmel to see if this is a max or a min spec.

Personally I find it ***extremely*** odd that Atmel uses and official
"unofficial" web site for providing this sort of info. I find that it is
full of vague information like this, but Atmel will refer you to AT91.com
for info! However, they say they are not responsible for the info there.
What is that about???

They should either exert enough control that it is *the* site for info on
those parts and it contains complete and accurate info or they should remove
it. We don't need a hobbyist web site for support.

Rick

--- In A... , Bill
Knight wrote:
>
> Rick
> Thanks for the info. I had seen that somewhere myself and checked.
> The VDDOUT signal rises at about 50V/ms. Much faster than the needed
6V/ms.
> Also, I do plan to replace at least a few of the rev B parts with rev
> As (once I locate them) and check the results. AND, I do have calls and
> emails into my FAE. It's just that with all the downsizing, he is
> stretched pretty thin and I do not know when he will be available to
> check into this.
>
> Thanks again.
> -Bill
>
> gnuarm wrote:
> > Bill,
> >
> > I did a search in the AT91.com web site forums and found this FAQ under
> > the heading of "Most known SAM7 Boot Problems". I'm not sure if they
> > mean most of the known problems or the problems that are most known...
> >
> > http://support.atmel.no/bin/customer?
&action=viewKbEntry&idr6
> >
> > Item 1 is something that may show up in a working design when the B
parts
> > are used, and would be very subtle. I'm not sure if this is your problem
> > or not, but it is worth a mention.
> >
> > Rick
> >
> > --- In A... , Bill
Knight wrote:
> >> techguy2000 wrote:
> >>> We've been using the SAM7 chips for several years with very few
> >>> problems, but Atmel seems to have introduced problems with the Rev B
> >>> devices. At least that seems to be where the troubles started.
> >>>
> >>> We've already hit the "must reset SPI port twice" unpublished
> >>> errata. In talking to Atmel support, they were aware of the problem,
> >>> but hadn't published as an errata. Nice product support.
> >>>
> >>> Now we're seeing a problem that I think has to do with the PLL.
> >>> We've recently had a noticeable percentage of devices that weren't
> >>> working or were working intermittently. I've seen a couple of
> >>> symptoms: Random data aborts during early initialization and finding
> >>> that the PIT timer wasn't counting and its registers indicating it
> >>> hadn't been programmed, even though I'm sure it was.
> >>>
> >>> Putting a short delay after the wait for the PLL lock bit, but
> >>> before making the PLLCLK/2 the master clock seems to fix the problem,
> >>> indicating that maybe the PLL hadn't really settled down when the lock
> >>> bit indicates it has.
> >>>
> >>> Anyone else seeing this problem?
> >>>
> >>> Cliff
> >> YES! I just started debugging a board with a number of SAM7S256 rev B
> >> parts all connected via on-board USB hub chips. The SAM-BA boot loader
> >> comes up fine and the parts can be programmed. The programmed code
> >> usually runs properly after pressing the on-board reset buttons.
> >> However, if the power is removed and reapplied the majority of the
> >> processors typically do not start up their oscillators. The design is
> >> one that has been running just fine w/ one processor per board (rev A
> >> parts). This version puts multiple processors on the same board and it
> >> is not at all reliable.
> >>
> >> I tried your suggestion of putting in a short delay and it does not
seem
> >> to help. I even have tried short delays between most of the
> >> initialization operations without success. Anyone have any additional
> >> suggestions?
> >>
> >> Like I said, what bugs me is that the SAM-BA boot loader seems to come
> >> up fine. Anyone know if the source code for is is available somewhere?
> >>
> >> Regards
> >> -Bill Knight
> >> R O SoftWare
>

Hmmmm... I read that item and realized it was not very well described. How do you know if that is a max or a min risetime? I don't have a lot of experience with this sort of "constraint". The only other one I remember encountering was on the Spartan 2 devices from Xilinx. The Vdd had to rise monotonically and I think it had a *max* rate of rise. You might want to contact Atmel to see if this is a max or a min spec.

Personally I find it ***extremely*** odd that Atmel uses and official "unofficial" web site for providing this sort of info. I find that it is full of vague information like this, but Atmel will refer you to AT91.com for info! However, they say they are not responsible for the info there. What is that about???

They should either exert enough control that it is *the* site for info on those parts and it contains complete and accurate info or they should remove it. We don't need a hobbyist web site for support.

Rick

--- In A..., Bill Knight wrote:
>
> Rick
> Thanks for the info. I had seen that somewhere myself and checked.
> The VDDOUT signal rises at about 50V/ms. Much faster than the needed 6V/ms.
> Also, I do plan to replace at least a few of the rev B parts with rev
> As (once I locate them) and check the results. AND, I do have calls and
> emails into my FAE. It's just that with all the downsizing, he is
> stretched pretty thin and I do not know when he will be available to
> check into this.
>
> Thanks again.
> -Bill
>
> gnuarm wrote:
> > Bill,
> >
> > I did a search in the AT91.com web site forums and found this FAQ under
> > the heading of "Most known SAM7 Boot Problems". I'm not sure if they
> > mean most of the known problems or the problems that are most known...
> >
> > http://support.atmel.no/bin/customer?=&action=viewKbEntry&idr6
> >
> > Item 1 is something that may show up in a working design when the B parts
> > are used, and would be very subtle. I'm not sure if this is your problem
> > or not, but it is worth a mention.
> >
> > Rick
> >
> > --- In A..., Bill Knight wrote:
> >> techguy2000 wrote:
> >>> We've been using the SAM7 chips for several years with very few
> >>> problems, but Atmel seems to have introduced problems with the Rev B
> >>> devices. At least that seems to be where the troubles started.
> >>>
> >>> We've already hit the "must reset SPI port twice" unpublished
> >>> errata. In talking to Atmel support, they were aware of the problem,
> >>> but hadn't published as an errata. Nice product support.
> >>>
> >>> Now we're seeing a problem that I think has to do with the PLL.
> >>> We've recently had a noticeable percentage of devices that weren't
> >>> working or were working intermittently. I've seen a couple of
> >>> symptoms: Random data aborts during early initialization and finding
> >>> that the PIT timer wasn't counting and its registers indicating it
> >>> hadn't been programmed, even though I'm sure it was.
> >>>
> >>> Putting a short delay after the wait for the PLL lock bit, but
> >>> before making the PLLCLK/2 the master clock seems to fix the problem,
> >>> indicating that maybe the PLL hadn't really settled down when the lock
> >>> bit indicates it has.
> >>>
> >>> Anyone else seeing this problem?
> >>>
> >>> Cliff
> >> YES! I just started debugging a board with a number of SAM7S256 rev B
> >> parts all connected via on-board USB hub chips. The SAM-BA boot loader
> >> comes up fine and the parts can be programmed. The programmed code
> >> usually runs properly after pressing the on-board reset buttons.
> >> However, if the power is removed and reapplied the majority of the
> >> processors typically do not start up their oscillators. The design is
> >> one that has been running just fine w/ one processor per board (rev A
> >> parts). This version puts multiple processors on the same board and it
> >> is not at all reliable.
> >>
> >> I tried your suggestion of putting in a short delay and it does not seem
> >> to help. I even have tried short delays between most of the
> >> initialization operations without success. Anyone have any additional
> >> suggestions?
> >>
> >> Like I said, what bugs me is that the SAM-BA boot loader seems to come
> >> up fine. Anyone know if the source code for is is available somewhere?
> >>
> >> Regards
> >> -Bill Knight
> >> R O SoftWare
>

Rick
Thanks for the info. I had seen that somewhere myself and checked.
The VDDOUT signal rises at about 50V/ms. Much faster than the needed 6V/ms.
Also, I do plan to replace at least a few of the rev B parts with rev
As (once I locate them) and check the results. AND, I do have calls and
emails into my FAE. It's just that with all the downsizing, he is
stretched pretty thin and I do not know when he will be available to
check into this.

Thanks again.
-Bill

gnuarm wrote:
> Bill,
>
> I did a search in the AT91.com web site forums and found this FAQ under
> the heading of "Most known SAM7 Boot Problems". I'm not sure if they
> mean most of the known problems or the problems that are most known...
>
> http://support.atmel.no/bin/customer?=&action=viewKbEntry&idr6
>
> Item 1 is something that may show up in a working design when the B parts
> are used, and would be very subtle. I'm not sure if this is your problem
> or not, but it is worth a mention.
>
> Rick
>
> --- In A..., Bill Knight wrote:
>> techguy2000 wrote:
>>> We've been using the SAM7 chips for several years with very few
>>> problems, but Atmel seems to have introduced problems with the Rev B
>>> devices. At least that seems to be where the troubles started.
>>>
>>> We've already hit the "must reset SPI port twice" unpublished
>>> errata. In talking to Atmel support, they were aware of the problem,
>>> but hadn't published as an errata. Nice product support.
>>>
>>> Now we're seeing a problem that I think has to do with the PLL.
>>> We've recently had a noticeable percentage of devices that weren't
>>> working or were working intermittently. I've seen a couple of
>>> symptoms: Random data aborts during early initialization and finding
>>> that the PIT timer wasn't counting and its registers indicating it
>>> hadn't been programmed, even though I'm sure it was.
>>>
>>> Putting a short delay after the wait for the PLL lock bit, but
>>> before making the PLLCLK/2 the master clock seems to fix the problem,
>>> indicating that maybe the PLL hadn't really settled down when the lock
>>> bit indicates it has.
>>>
>>> Anyone else seeing this problem?
>>>
>>> Cliff
>> YES! I just started debugging a board with a number of SAM7S256 rev B
>> parts all connected via on-board USB hub chips. The SAM-BA boot loader
>> comes up fine and the parts can be programmed. The programmed code
>> usually runs properly after pressing the on-board reset buttons.
>> However, if the power is removed and reapplied the majority of the
>> processors typically do not start up their oscillators. The design is
>> one that has been running just fine w/ one processor per board (rev A
>> parts). This version puts multiple processors on the same board and it
>> is not at all reliable.
>>
>> I tried your suggestion of putting in a short delay and it does not seem
>> to help. I even have tried short delays between most of the
>> initialization operations without success. Anyone have any additional
>> suggestions?
>>
>> Like I said, what bugs me is that the SAM-BA boot loader seems to come
>> up fine. Anyone know if the source code for is is available somewhere?
>>
>> Regards
>> -Bill Knight
>> R O SoftWare

Bill,

I did a search in the AT91.com web site forums and found this FAQ under the heading of "Most known SAM7 Boot Problems". I'm not sure if they mean most of the known problems or the problems that are most known...

http://support.atmel.no/bin/customer?=&action=viewKbEntry&idr6

Item 1 is something that may show up in a working design when the B parts are used, and would be very subtle. I'm not sure if this is your problem or not, but it is worth a mention.

Rick

--- In A..., Bill Knight wrote:
>
> techguy2000 wrote:
> > We've been using the SAM7 chips for several years with very few
> > problems, but Atmel seems to have introduced problems with the Rev B
> > devices. At least that seems to be where the troubles started.
> >
> > We've already hit the "must reset SPI port twice" unpublished
> > errata. In talking to Atmel support, they were aware of the problem,
> > but hadn't published as an errata. Nice product support.
> >
> > Now we're seeing a problem that I think has to do with the PLL.
> > We've recently had a noticeable percentage of devices that weren't
> > working or were working intermittently. I've seen a couple of
> > symptoms: Random data aborts during early initialization and finding
> > that the PIT timer wasn't counting and its registers indicating it
> > hadn't been programmed, even though I'm sure it was.
> >
> > Putting a short delay after the wait for the PLL lock bit, but
> > before making the PLLCLK/2 the master clock seems to fix the problem,
> > indicating that maybe the PLL hadn't really settled down when the lock
> > bit indicates it has.
> >
> > Anyone else seeing this problem?
> >
> > Cliff
>
> YES! I just started debugging a board with a number of SAM7S256 rev B
> parts all connected via on-board USB hub chips. The SAM-BA boot loader
> comes up fine and the parts can be programmed. The programmed code
> usually runs properly after pressing the on-board reset buttons.
> However, if the power is removed and reapplied the majority of the
> processors typically do not start up their oscillators. The design is
> one that has been running just fine w/ one processor per board (rev A
> parts). This version puts multiple processors on the same board and it
> is not at all reliable.
>
> I tried your suggestion of putting in a short delay and it does not seem
> to help. I even have tried short delays between most of the
> initialization operations without success. Anyone have any additional
> suggestions?
>
> Like I said, what bugs me is that the SAM-BA boot loader seems to come
> up fine. Anyone know if the source code for is is available somewhere?
>
> Regards
> -Bill Knight
> R O SoftWare
>

Jerry
Thanks for the update, though the news isn't encouraging. It just
bugs me that the SAM-BA boot loader seems to come up reliably on the USB
connection but I cannot get the same results. I haven't replaced the
rev B parts on the new board with rev A's in oder to compare results but
seeing as the design is almost a cut-and-paste of a working design
(using rev A parts), I expect the rev A parts would work as they are
suppose to.

Again, sure wish I could get my eyes on the source of at least the
startup portion of the SAM-BA boot loader code that is in the part.

We have a build pending that would use up to 3,200 SAM7S256's, but
not until I can get this resolved.

Anyway Jerry, thanks for the info. I'll keep you and the group
posted about any successes I can manage.

-Bill Knight
R O SoftWare

Jerry West wrote:
> I have been building products with the AT91SAM7S256 for 3 years. I had
> no problems with the first 1000 units which were constructed with Rev A
> parts. The next 1000 were built with Rev B parts and about 80% of the
> units would intermittently halt on power up with a data abort. I could
> not find a reason and bought Rev A parts on the surplus market. The
> boards all worked.
>
> I am now facing the problem again as no Rev A parts are located. I used
> a 20.48 MHz crystal and had the PLL double the CPU clock to 40.96 MHz.
>
> I have just redesigned the PCB to use an external oscillator since I was
> cheating on the upper frequency limit of 20.0 MHz at 20.48 MHz. I have
> not started the debug effort yet but will be in it next week. I do wish
> Atmel would tell us what they changed.
>
> Jerry
>
>
>
> *From:* A... [mailto:A...] *On
> Behalf Of *Bill Knight
> *Sent:* Wednesday, September 02, 2009 3:15 PM
> *To:* A...
> *Subject:* Re: [AT91SAM] Yet another problem with Rev B AT91SAM7's
>
>
> techguy2000 wrote:
> > We've been using the SAM7 chips for several years with very few
> > problems, but Atmel seems to have introduced problems with the Rev B
> > devices. At least that seems to be where the troubles started.
> >
> > We've already hit the "must reset SPI port twice" unpublished
> > errata. In talking to Atmel support, they were aware of the problem,
> > but hadn't published as an errata. Nice product support.
> >
> > Now we're seeing a problem that I think has to do with the PLL.
> > We've recently had a noticeable percentage of devices that weren't
> > working or were working intermittently. I've seen a couple of
> > symptoms: Random data aborts during early initialization and finding
> > that the PIT timer wasn't counting and its registers indicating it
> > hadn't been programmed, even though I'm sure it was.
> >
> > Putting a short delay after the wait for the PLL lock bit, but
> > before making the PLLCLK/2 the master clock seems to fix the problem,
> > indicating that maybe the PLL hadn't really settled down when the lock
> > bit indicates it has.
> >
> > Anyone else seeing this problem?
> >
> > Cliff
>
> YES! I just started debugging a board with a number of SAM7S256 rev B
> parts all connected via on-board USB hub chips. The SAM-BA boot loader
> comes up fine and the parts can be programmed. The programmed code
> usually runs properly after pressing the on-board reset buttons.
> However, if the power is removed and reapplied the majority of the
> processors typically do not start up their oscillators. The design is
> one that has been running just fine w/ one processor per board (rev A
> parts). This version puts multiple processors on the same board and it
> is not at all reliable.
>
> I tried your suggestion of putting in a short delay and it does not seem
> to help. I even have tried short delays between most of the
> initialization operations without success. Anyone have any additional
> suggestions?
>
> Like I said, what bugs me is that the SAM-BA boot loader seems to come
> up fine. Anyone know if the source code for is is available somewhere?
>
> Regards
> -Bill Knight
> R O SoftWare