Selecting Microcontrollers

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

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

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

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

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