Thanks for the suggestions and conformations. I've at least verified that
some of the crystals I have on hand will work in the oscillator circuit (my
Olimex board). Now if I could just get my prototype board to download via
JTAG!

Alan KM6VV
>
> --- In A..., "Alan KM6VV" wrote:
> >> I had ran into the JTAGSEL and ERASE lines, they had been tied down,
> >>I had intended them to float, as the examples I'd seen. No change.
> >>ERASE would have caused a problem, the chip would have been erased
> >>each power up!
>
> I would not recommend floating the ERASE(and TST) pin but tie it hard
> to ground or through a small resistor. We found that a small drop of
> moisture condensation on the pin is enough to overcome the internal
> pulldown and cause a chip erase. Not a good thing for the customer.
>
> As others stated, the AT91SAM runs on an internal clk until you enable
> the xtal osc. Also, the voltage swing on the crystal is very small,
> not at logic levels so it may look dead unless you crank up the scope
> gain.
>
> Moe
>

--- In A..., "Alan KM6VV" wrote:
>> I had ran into the JTAGSEL and ERASE lines, they had been tied down,
>>I had intended them to float, as the examples I'd seen. No change.
>>ERASE would have caused a problem, the chip would have been erased
>>each power up!

I would not recommend floating the ERASE(and TST) pin but tie it hard
to ground or through a small resistor. We found that a small drop of
moisture condensation on the pin is enough to overcome the internal
pulldown and cause a chip erase. Not a good thing for the customer.

As others stated, the AT91SAM runs on an internal clk until you enable
the xtal osc. Also, the voltage swing on the crystal is very small,
not at logic levels so it may look dead unless you crank up the scope
gain.

Moe

Hi Rick,

Yeah, I'm in the "verify everything" mode! I don't see the ID's anywhere
either, but my EK ID's the core the same. And I'm able to develop RAM/Flash
successfully there.

I had ran into the JTAGSEL and ERASE lines, they had been tied down, I had
intended them to float, as the examples I'd seen. No change. ERASE would
have caused a problem, the chip would have been erased each power up! But
at least I would have had JTAG working. I'm going to look at that JTAG line
again. I'd be happier if they matched my ID's from the EK. Boundary scan
mode could explain a lot.

The chips were received about two weeks ago, and also I have a few from
about 4-5 months ago, they also are AU. Both stocks from Digikey.

I also found in my stock from 4-5 months ago a bag of ABL-18.432MHz-B2
xtals, Digikey 535-9044-ND, and an Olimex SAM7-256 header. It too has a
AU-001 marked chip, and, I discovered, a socketed xtal. I tried the ABL in
it, and it doesn't come up. Olimex has 10pF caps. Next quick test is to
have my tech (my eyes are too bad) solder some wires onto the SM ABM3B
xtals, and I'll try them. Another PCB board is also being populated,
perhaps it'll fair better (couldn't hurt).

Thanks,

Alan KM6VV
P.S. calls into my FE also.
> >
> > I did get a "found 1 JTAG device. ARM core id: 3F0F0F0F (ARM7) which is
> > encouraging.
>
> I'm not sure this is encouraging. This ID does not match any of the
> chips in the SAM7S data sheet. Check it out.
> > I've also noticed that the Chip ID, Extension, and Flash codes as
> read by
> > jtag are all different then on the EK. Also, the part we stuffed
> our boards
> > with is AU, not AU-001 as seen on EK and other demo board. We
> bought from
> > DigiKey, AT91SAM7S256-AU-001, LQFP.
>
> See page 525 for info on chip markings. Is it possible that you have
> a really old chip that is pre-production??? I don't know how you
> could get the wrong Chip ID from JTAG. Hmmm... any chance the JTAGSEL
> pin is not in the right state? That would put you in boundary scan
> and would likely give very different responses than when in JTAG debug
> mode. I see the definition of a boundary scan ID Code Register, but
> it does not give this result either... But if the ICE thinks it is in
> JTAG mode and it is really in boundary scan mode, there is no telling
> what register it is really reading. The JTAGSEL pin should be low or
> floating (pulled low internally). Check it with a meter... :^)
>
> When nothing seems to make sense, verify *everything*.

--- In A..., "Alan KM6VV" wrote:
>
> I should be very close to the reference design (EK) as far as the
processor
> is concerned. I've carefully checked power, the jtag connections, and
> especially the reset from the jtag. Comparing the Jtag debug output
(while
> attempting to download to the EK), and warning messages indicate
that the
> jtag seems to be having trouble resetting the uP, although it does
get down
> to a file load and say it loaded debugee (sic) 4955 bytes.
Apparently this
> is the download debugger, and after a "target reset", the last
message I get
> is "non-zero or missing exit code", so I'm thinking the reset wasn't any
> good.
>
> Before the download, Jtag appears to attempt to shift to "TRST" to
try to
> reset, but on the EK and my proto board (and another example I've
studied),
> TRST is just pulled up. "NRST" is the one connected to jtag in the
EK and
> other board, and mine.
>
> I did get a "found 1 JTAG device. ARM core id: 3F0F0F0F (ARM7) which is
> encouraging.

I'm not sure this is encouraging. This ID does not match any of the
chips in the SAM7S data sheet. Check it out.
> I've also noticed that the Chip ID, Extension, and Flash codes as
read by
> jtag are all different then on the EK. Also, the part we stuffed
our boards
> with is AU, not AU-001 as seen on EK and other demo board. We
bought from
> DigiKey, AT91SAM7S256-AU-001, LQFP.

See page 525 for info on chip markings. Is it possible that you have
a really old chip that is pre-production??? I don't know how you
could get the wrong Chip ID from JTAG. Hmmm... any chance the JTAGSEL
pin is not in the right state? That would put you in boundary scan
and would likely give very different responses than when in JTAG debug
mode. I see the definition of a boundary scan ID Code Register, but
it does not give this result either... But if the ICE thinks it is in
JTAG mode and it is really in boundary scan mode, there is no telling
what register it is really reading. The JTAGSEL pin should be low or
floating (pulled low internally). Check it with a meter... :^)

When nothing seems to make sense, verify *everything*.

Hi Rick, List,

Thanks for your comments.

I studied the debug for SAM-ICE, and compared it to that of an EK board.
Certainly sounds like starts off slow (30Khz) like you state, and after
loading my 187 pages, reset and shift master clock to 48MHz. I don't get
that far on my prototype board!

I should be very close to the reference design (EK) as far as the processor
is concerned. I've carefully checked power, the jtag connections, and
especially the reset from the jtag. Comparing the Jtag debug output (while
attempting to download to the EK), and warning messages indicate that the
jtag seems to be having trouble resetting the uP, although it does get down
to a file load and say it loaded debugee (sic) 4955 bytes. Apparently this
is the download debugger, and after a "target reset", the last message I get
is "non-zero or missing exit code", so I'm thinking the reset wasn't any
good.

Before the download, Jtag appears to attempt to shift to "TRST" to try to
reset, but on the EK and my proto board (and another example I've studied),
TRST is just pulled up. "NRST" is the one connected to jtag in the EK and
other board, and mine.

I did get a "found 1 JTAG device. ARM core id: 3F0F0F0F (ARM7) which is
encouraging.

I've also noticed that the Chip ID, Extension, and Flash codes as read by
jtag are all different then on the EK. Also, the part we stuffed our boards
with is AU, not AU-001 as seen on EK and other demo board. We bought from
DigiKey, AT91SAM7S256-AU-001, LQFP.

Thanks again for your help.

Alan KM6VV

>
> I am not aware of any issues that require a chip to be programmed to
> get the oscilator running. But it has been a year since I worked with
> this part. I seem to recall that the part comes up using the internal
> oscillator and the software has to switch it to the crystal or PLL.
> But I work with so many chips I sometimes get them mixed up. I
> suggest you check the manual on this. I think the SAM7 parts also
> require a filter for the PLL to work correctly. In fact there is a
> tool to help you design this filter for the exact frequency you are
> working with. Did you see that software? We found that the filter
> component values on the eval board work fine at 18.432 MHz.
>
> > Humm, I just saw something under Main Osc Control on pg. 210. I've only
> > seen the -256-EK eval kit; so is there something different on a RAW
> chip
> > for startup? It is sounding like I have to program it before it
> will turn
> > on the Osc? I have been using SAM-ICE (J-TAG) and the IAR C
> compiler. I
> > tried my J-TAG on the new board; it can't ID it or something (or do
> reset).
> > J-TAG is a separate clock that "takes over" when it downloads to
> flash or
> > RAM as I understand.
>
> Yes, that is what I recalled. The chip starts up using the internal
> "slow clock" which is roughly 32 kHz +- 30%! I can't recall how this
> is dealt with by the JTAG. I do recall that on other Atmel chips that
> start up in a slow clock mode that you have to run the JTAG slower
> than the CPU clock. The JTAG clock can control some things like I/O
> for boundary scan, but I am not sure it can clock the rest of the
> chip. But I thought the debugger handled this automatically. I never
> had to do anything to make the eval board work, but then it was always
> programmed to come up running from the Flash.
>

--- In A..., "Alan KM6VV" wrote:
>
> Hi Rick,
>
> Thanks for the information and the recommendation. We have a
surface mount
> ABM3B xtal currently (first PCB). And the ABL-18 you recommend
looks good
> as well, kinda what I thought. So it seems like it should be the
correct
> part. We're going over the chip (again) to see if any of the pins
have the
> wrong supply voltage, or shorts. I don't know of any other reason
that an
> un-programmed chip wouldn't oscillate.

I am not aware of any issues that require a chip to be programmed to
get the oscilator running. But it has been a year since I worked with
this part. I seem to recall that the part comes up using the internal
oscillator and the software has to switch it to the crystal or PLL.
But I work with so many chips I sometimes get them mixed up. I
suggest you check the manual on this. I think the SAM7 parts also
require a filter for the PLL to work correctly. In fact there is a
tool to help you design this filter for the exact frequency you are
working with. Did you see that software? We found that the filter
component values on the eval board work fine at 18.432 MHz.
> Funny, my Doc6175E data sheet has the xtal info elsewhere! It still is
> confusing to see a spec for a uP with internal caps on the osc. pins.

Yes, I couldn't find enough info to select a crystal and I knew that
the smaller part I wanted to use had to be matched to the oscillator.
So I bugged them until the designer came back with some data and they
added it to the newest data sheet. Oddly enough they don't tell you
what ESR to use in between the frequencies specified. I had to
contact them again to find that at 18.432 MHz a 60 ohm max ESR is ok.
> OK, I
> just figured I'd maybe have to add small caps to bring it up from
12.5 to 18
> pF. But you recall 20 pF? I downloaded the 6175G document.

That is what I was told by my FAE. However verbal info can be out of
date and this part has been out for a while now. I suggest that you
contact Atmel if it matters to you. You can leave pads for caps and
then assemble them as needed.
> Humm, I just saw something under Main Osc Control on pg. 210. I've only
> seen the -256-EK eval kit; so is there something different on a RAW
chip
> for startup? It is sounding like I have to program it before it
will turn
> on the Osc? I have been using SAM-ICE (J-TAG) and the IAR C
compiler. I
> tried my J-TAG on the new board; it can't ID it or something (or do
reset).
> J-TAG is a separate clock that "takes over" when it downloads to
flash or
> RAM as I understand.

Yes, that is what I recalled. The chip starts up using the internal
"slow clock" which is roughly 32 kHz +- 30%! I can't recall how this
is dealt with by the JTAG. I do recall that on other Atmel chips that
start up in a slow clock mode that you have to run the JTAG slower
than the CPU clock. The JTAG clock can control some things like I/O
for boundary scan, but I am not sure it can clock the rest of the
chip. But I thought the debugger handled this automatically. I never
had to do anything to make the eval board work, but then it was always
programmed to come up running from the Flash.

You might want to check comp.arch.embedded in Google Groups where
there are lots of other people who can give you good advice on this
problem. I just don't recall the details.

Hi Rick,

Thanks for the information and the recommendation. We have a surface mount
ABM3B xtal currently (first PCB). And the ABL-18 you recommend looks good
as well, kinda what I thought. So it seems like it should be the correct
part. We're going over the chip (again) to see if any of the pins have the
wrong supply voltage, or shorts. I don't know of any other reason that an
un-programmed chip wouldn't oscillate.

Funny, my Doc6175E data sheet has the xtal info elsewhere! It still is
confusing to see a spec for a uP with internal caps on the osc. pins. OK, I
just figured I'd maybe have to add small caps to bring it up from 12.5 to 18
pF. But you recall 20 pF? I downloaded the 6175G document.

Humm, I just saw something under Main Osc Control on pg. 210. I've only
seen the -256-EK eval kit; so is there something different on a RAW chip
for startup? It is sounding like I have to program it before it will turn
on the Osc? I have been using SAM-ICE (J-TAG) and the IAR C compiler. I
tried my J-TAG on the new board; it can't ID it or something (or do reset).
J-TAG is a separate clock that "takes over" when it downloads to flash or
RAM as I understand.

Thanks for your help!

Alan KM6VV
> On Behalf Of Rick Collins
>
> I forgot to recommend a part. I checked Digikey and there are a huge
> number of parts available. The Abracon ABL-18.432MHZ-B2 is in an
> HC49US can and has an ESR of 40 ohms at 16 MHz and above. This part
> is rated for 18 pF shunt capacitance, so it is pretty close to the 20
> pF I seem to recall the SAM7 chips providing. If your FAE says the
> data sheet is correct and it is not 20 pF, you will need to add
> capacitors to suit.
>
> If you would prefer a surface mount part, Digikey seems to have plenty
> of those too.
> Yahoo! Groups Links
>

> My guess is that 22.11 MHz would
> work ok, but that it may have difficulty with
> startup, particularly at
> low temperatures. It is hard to tell if Atmel is
> being overly
> conservative or not. But if your project does not
> need to operate
> below room temp, then you might be able to make this
> work.

It is working at room temp, but I am redisigning a
product which is spread over 10 countries and I don't
want to take that risk ;-)

> I am familiar with this errata. If you are facing
> the frequency
> limitation, then you must be working with the
> SAM7S64 or the SAM7S32.
> These are the only two parts which are not
> available in the 'A'
> version and have this particular errata. If you can
> work with one of
> the other versions, like the 7S321 or the 7S128, you
> can use an 'A'
> version and don't need to worry about it.

How stupid I am... Indeed, I have started with SAM7S64
but for some reasons I moved to SAM7X and I didn't
realized until now that 3-19MHz is no longer a
problem.
Thank you very much for pointing me this out :-)

> Have you measured the power consumption difference
> in using the PLL vs
> the direct clock? Is it clear that the startup time
> of the PLL draws
> significant current for your project?
In fact I am not using PLL but I was going to. The
problem is that I have a graphical LCD and small GUI.
Since the GUI rendering (menus etc) is a low priority
task there is a noticeable delay between the key
pressing and display update.
The comsumption of the whole device is about 1mA @ 8V
with the CPU runinng @ 2.3MHz. I am not stopping the
CPU yet because it is still a debug phase and the JTAG
dies when the CPU clock is below the JTAG clock.
Anyway, I think the specs are correct about
consumption and I get reasonably close to what is
expected.
I haven't measured the PLL consumtion during its
startup time, but during normal operation it has 2-3mA
alone. This is more than what I have now from the
whole chip. Fortunately, thanks to your tip I don't
have to use the PLL at all - I will just increase the
CPU clock up to 9 or 18MHz in the worst case.

I so happy now that I don't have to use the PLL just
to get out of the 3-19 range ;-)

Cheers,
Miro

__________________________________________________

--- In A..., Miroslav Kostadinov wrote:
>
> The datasheet says that the maximum oscillator
> frequency is 20MHz. Is there any particular reason for
> this limitation? How safe is to use let say 22.11MHz ?

I could not answer that question. The reason for the 20 MHz limit is
not something I am familiar with. My guess is that 22.11 MHz would
work ok, but that it may have difficulty with startup, particularly at
low temperatures. It is hard to tell if Atmel is being overly
conservative or not. But if your project does not need to operate
below room temp, then you might be able to make this work.
> This is VERY IMPORTANT to me as my project is battery
> powered 24 hours a day and should work months between
> recharges.
> You know that the consumption depends on the
> frequency, so I would like to run as slow as possible.
> At the moment I use 18MHz crystal, but I need the
> flash so the 3-19MHz range is forbidden for me and I
> can work only up to 1/8 of the oscillator or 2.3MHz.
> However, on time to time I need little bit more
> processing power. And then the problems starts -
> turning the PLL on takes time and increases the
> consumption big time. Switching between 2.3Mhz and pll
> frequency back and forth cannot be done directly.

I am familiar with this errata. If you are facing the frequency
limitation, then you must be working with the SAM7S64 or the SAM7S32.
These are the only two parts which are not available in the 'A'
version and have this particular errata. If you can work with one of
the other versions, like the 7S321 or the 7S128, you can use an 'A'
version and don't need to worry about it.
> If 22.11Mhz is available I could solve many many
> problems with the consumption, performance, UART
> baudrates etc...

Have you measured the power consumption difference in using the PLL vs
the direct clock? Is it clear that the startup time of the PLL draws
significant current for your project?

I ask because I received a spread sheet that shows the current
consumption of the SAM7 parts as a function of clock speed and
sections enabled. I seem to recall that the PLL did not use a lot of
power relative to the rest of the chip. The startup time is another
thing. If you are going to sleep for long times and run for a short
time when you wake up, then startup time can draw significant power.

If you would like the power consumption spread sheet, it was put
togetther by Durant Lewis, an FAE. I may have the last name wrong,
but he covers the Washington, DC area. You can ask your FAE to get it
for you. I don't know for sure that it has been validated against the
silicon. I may be a tool put together by the FAEs without input from
the design team, I am not sure. If you are measuring your power
consumption, then you certainly don't need this.

> You came to the right place. I am the guy who is
> responsible for
> Atmel adding crystal characteristics to their data
> sheet.

Hi Rick,

I am so happy to hear this, I have another question
about the oscillator frequency which is:

The datasheet says that the maximum oscillator
frequency is 20MHz. Is there any particular reason for
this limitation? How safe is to use let say 22.11MHz ?

This is VERY IMPORTANT to me as my project is battery
powered 24 hours a day and should work months between
recharges.
You know that the consumption depends on the
frequency, so I would like to run as slow as possible.
At the moment I use 18MHz crystal, but I need the
flash so the 3-19MHz range is forbidden for me and I
can work only up to 1/8 of the oscillator or 2.3MHz.
However, on time to time I need little bit more
processing power. And then the problems starts -
turning the PLL on takes time and increases the
consumption big time. Switching between 2.3Mhz and pll
frequency back and forth cannot be done directly.

If 22.11Mhz is available I could solve many many
problems with the consumption, performance, UART
baudrates etc...

Regards,
Miro

__________________________________________________