Yet another problem with Rev B AT91SAM7's

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
Start a New Thread

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

Start a New Thread

--- In A..., "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
Start a New Thread

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

Start a New Thread

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... [mailto:A...] On Behalf Of
miro_atc
Sent: Tuesday, 16 September 2008 8:48 PM
To: A...
Subject: [AT91SAM] Re: any 802.11 gurus ? unknown Information Element

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

Start a New Thread

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... [mailto:A...] On Behalf Of
capiman26061973
Sent: Tuesday, 16 September 2008 10:05 PM
To: A...
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

Start a New Thread

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
Start a New Thread

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 Start a New Thread

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..., "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
>
Start a New Thread

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
Start a New Thread