Sign in

Search AT91SAM

Subscribe to AT91SAM

Sponsor

controlSUITE™ software
Comprehensive.
Intuitive.
Optimized.
Real-world software for real-time control. Details Here!

Discussion Groups

Discussion Groups | AT91SAM ARM | Yet another problem with Rev B AT91SAM7's

For users of the Atmel AT91SAM7 and AT91SAM9 ARM CPU chips. Atmel has taken a new direction by combining on chip flash and ram with the ARM CPU on a single die. This provides low cost devices for small systems using the ARM CPU. This group is to exchange information to help users get started and learn how to use the devices.

Yet another problem with Rev B AT91SAM7's - techguy2000 - Sep 15 16:02:10 2008

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
------------------------------------

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

any 802.11 gurus ? unknown Information Element - Microbit_P43000 - Sep 16 6:02:11 2008

Hi gurus,

I've been writing a SAM7 driver for an SDIO WiFi card. All going well, but
because I have to implement the 802.11 MAC state machines myself, there's an
information element I can't find anything on. I don't need it per se - I
think - but I'd like to know whether it is important/relevant :

In response to an association request or a probe request, my router returns
the following information element at the end of the response frame :

DD 06 00 10 18 02 02 F0

The Information ID is 0xDD, length 06 with field 00 10 18 02 02 F0

I can't find anything on this, nor in the 802.11 standard, nor on Google.
The only hits I get are to do with various patents.
This relates to 802.11b - 802.11i

This information element is the last in the Probe Response or Association
Response, and follows the "Basic supported Rates" Information element :

01 04 82 84 8B 96

I've tried with 2 different access points, both return the same
"vendor-specific" (According to 802.11 -2007 standard) 0xDD Information ID.

Does anyone have a list of Information Ids where DD appears, or know what it
means ???

Best regards,
Kris

------------------------------------

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: any 802.11 gurus ? unknown Information Element - miro_atc - Sep 16 6:48:49 2008

--- In A...@yahoogroups.com, "Microbit_P43000"
wrote:
> I can't find anything on this, nor in the 802.11 standard, nor on
Google.

Kris, I can't help you with the problem, but I can recommend you to
check http://www.wireshark.org/

They have pretty advanced sniffer which can analyze hundreds of
protocols and if you are lucky you will see what is the meaning of
your binary data...
btw it's interesting project, I may have to do something like this
next year, so good luck and keep us posted ;-)

miro
------------------------------------

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: any 802.11 gurus ? unknown Information Element - capiman26061973 - Sep 16 8:05:31 2008

Hello Kris,

> DD 06 00 10 18 02 02 F0

i also can't help, but have you checked if the 6 bytes are not equal to
the MAC address ?

Another question: Which SDIO Wifi card are you using ? Is there
documentation available for private purposes, without signing an NDA ?
Is there a possibility to share your sources ?

Regards,

Martin

------------------------------------

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

RE: Re: any 802.11 gurus ? unknown Information Element - Microbit_P43000 - Sep 16 8:50:22 2008

Hi Miro,

I thought wireshark was the same as Ethereal, but I presume it's a
commercial extension?
I tried with Ethereal, but my (older) digimate USB 802.11b adapters don't
appear to support promiscuous mode :-(
(IOW I can' t capture raw 802.11 packets, but I can capture at IP level)

In the meantime I figured out what the information is, I'll comment in the
other reply.

Best Regards,
Kris
-----Original Message-----
From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of
miro_atc
Sent: Tuesday, 16 September 2008 8:48 PM
To: A...@yahoogroups.com
Subject: [AT91SAM] Re: any 802.11 gurus ? unknown Information Element

--- In A...@yahoogroups.com, "Microbit_P43000"
wrote:
> I can't find anything on this, nor in the 802.11 standard, nor on
Google.

Kris, I can't help you with the problem, but I can recommend you to
check http://www.wireshark.org/

They have pretty advanced sniffer which can analyze hundreds of
protocols and if you are lucky you will see what is the meaning of
your binary data...
btw it's interesting project, I may have to do something like this
next year, so good luck and keep us posted ;-)

miro

------------------------------------

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

RE: Re: any 802.11 gurus ? unknown Information Element - Microbit_P43000 - Sep 16 8:56:41 2008

Hi Martin,

In the meantime I figured out that DD = 221 = WPA_INFO_ELEM.

It contains the SUITE_SELECTOR & version.
SUITE_SELECTOR structure holds oui (3 bytes) & type (1 byte)

> Another question: Which SDIO Wifi card are you using ?

I'm using SDW-820 Spectec

> Is there documentation available for private purposes, without signing an
NDA ?

I signed an NDA with Spectec :-(

> Is there a possibility to share your sources ?

Not at this stage, I will have to see where I go with this, sorry..
I got some WINCE code which I've had to reverse engineer on for weeks to
figure out how to talk to the IPN2128 chipset - it's extremely complex.

Best Regards,
Kris

-----Original Message-----
From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of
capiman26061973
Sent: Tuesday, 16 September 2008 10:05 PM
To: A...@yahoogroups.com
Subject: [AT91SAM] Re: any 802.11 gurus ? unknown Information Element

Hello Kris,

> DD 06 00 10 18 02 02 F0

i also can't help, but have you checked if the 6 bytes are not equal to
the MAC address ?

Another question: Which SDIO Wifi card are you using ? Is there
documentation available for private purposes, without signing an NDA ?
Is there a possibility to share your sources ?

Regards,

Martin

------------------------------------

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Yet another problem with Rev B AT91SAM7's - Bill Knight - Sep 2 16:16:05 2009

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
------------------------------------

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

RE: Yet another problem with Rev B AT91SAM7's - Jerry West - Sep 2 16:37:12 2009

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...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of
Bill Knight
Sent: Wednesday, September 02, 2009 3:15 PM
To: A...@yahoogroups.com
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
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Yet another problem with Rev B AT91SAM7's - gnuarm - Sep 2 16:56:43 2009

Have you guys contacted your FAE or other reps? I know that often they are not much help, but this is just the sort of problem that they should at least know about and they likely can put you in touch with someone who does know what is going on. I think I'll pass this thread on to my local FAE and see if he knows anything about it.

Rick
--- In A...@yahoogroups.com, "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...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of
> Bill Knight
> Sent: Wednesday, September 02, 2009 3:15 PM
> To: A...@yahoogroups.com
> 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
>
------------------------------------

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Yet another problem with Rev B AT91SAM7's - Bill Knight - Sep 2 17:11:16 2009

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...@yahoogroups.com [mailto:A...@yahoogroups.com] *On
> Behalf Of *Bill Knight
> *Sent:* Wednesday, September 02, 2009 3:15 PM
> *To:* A...@yahoogroups.com
> *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
------------------------------------

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Yet another problem with Rev B AT91SAM7's - gnuarm - Sep 2 17:16:22 2009

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&id=726

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...@yahoogroups.com, 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
>
------------------------------------

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Re: Yet another problem with Rev B AT91SAM7's - Bill Knight - Sep 2 17:32:28 2009

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&id=726
>
> 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...@yahoogroups.com, 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
------------------------------------

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Yet another problem with Rev B AT91SAM7's - gnuarm - Sep 2 17:49:14 2009

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...@yahoogroups.com, 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&id=726
> >
> > 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...@yahoogroups.com, 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
>
------------------------------------

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

RE: Re: Yet another problem with Rev B AT91SAM7's - Jerry West - Sep 2 18:11:34 2009

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

Jw

From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of
gnuarm
Sent: Wednesday, September 02, 2009 4:49 PM
To: A...@yahoogroups.com
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...@yahoogroups.com , 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&id=726
> >
> > 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...@yahoogroups.com , 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
>

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Yet another problem with Rev B AT91SAM7's - stef33d - Sep 3 10:56:18 2009

--- In A...@yahoogroups.com, "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
------------------------------------

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

(ATTicket:560406) Re: Yet another problem with Rev B AT91SAM7's - Bill Knight - Sep 17 13:13:11 2009

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...@yahoogroups.com [mailto:A...@yahoogroups.com] *On
>> Behalf Of *Bill Knight
>> *Sent:* Wednesday, September 02, 2009 3:15 PM
>> *To:* A...@yahoogroups.com
>> *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
------------------------------------

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: (ATTicket:560406) Re: Yet another problem with Rev B AT91SAM7's - Ralph Hempel - Sep 17 13:26:48 2009

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

------------------------------------

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: (ATTicket:560406) Re: Yet another problem with Rev B AT91SAM7's - Stephen Manion - Sep 17 17:21:16 2009

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
******************************

(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )