Hi,
Selecting the micros, depends on
1. Memory & Peripheral Requirement
2. Cost of the IC
3. Support(Cost of Debugger, Cost of Compiler & general
enquiry/help) from the Microcontroller manufacturers.
4. Type of Application
Item one is must for any project.
Item two to four, we have to do much analysis, before investing.
I heard from discussion with friends that Microchip ICs & tools
are costliest on small to mid range application. But ATMEL is better
on that aspect. Is it true?
And for mid-range application, how AT91SAM(ATMEL) is better than
LPC21XX(NXP)?
Please let me know, somebody, have this kind of analysis.
Thanks & Regards,
R.Ayyappan
Selecting Microcontrollers
Started by ●April 23, 2007
Reply by ●April 23, 20072007-04-23
This is a good way to start an argument. Almost as bad as saying "Selecting a
religion".
On Tuesday 24 April 2007 03:12, ipan_dgl wrote:
> Hi,
>
> Selecting the micros, depends on
> 1. Memory & Peripheral Requirement
> 2. Cost of the IC
> 3. Support(Cost of Debugger, Cost of Compiler & general
> enquiry/help) from the Microcontroller manufacturers.
> 4. Type of Application
>
> Item one is must for any project.
>
> Item two to four, we have to do much analysis, before investing.
>
> I heard from discussion with friends that Microchip ICs & tools
> are costliest on small to mid range application. But ATMEL is better
> on that aspect. Is it true?
There are no Atmel or NXP specific tools for ARM development (except for
thiongs like the NXP downloader program). They can all work with the same
compilers, debuggers etc. This is one reason why I use them in preference
over PIC etc.
>
> And for mid-range application, how AT91SAM(ATMEL) is better than
> LPC21XX(NXP)?
Which is better a Ferrari or a Volswagen? Well if you want to drive around the
roads near me, then the Volkswagen is better.
They are different, with different peripheral mixes and capabilities.
The SAM parts have peripheral DMA, which is noce, but the TWI (I2C)
implementation is very buggy.
>From what I have observed, the NXP support people are far better at
interacting with groups like this than Atmel are.
Ultimately the engineering effort will be similar to use each and things like
peripheral mix, and cost, will be determined by project requirements.
religion".
On Tuesday 24 April 2007 03:12, ipan_dgl wrote:
> Hi,
>
> Selecting the micros, depends on
> 1. Memory & Peripheral Requirement
> 2. Cost of the IC
> 3. Support(Cost of Debugger, Cost of Compiler & general
> enquiry/help) from the Microcontroller manufacturers.
> 4. Type of Application
>
> Item one is must for any project.
>
> Item two to four, we have to do much analysis, before investing.
>
> I heard from discussion with friends that Microchip ICs & tools
> are costliest on small to mid range application. But ATMEL is better
> on that aspect. Is it true?
There are no Atmel or NXP specific tools for ARM development (except for
thiongs like the NXP downloader program). They can all work with the same
compilers, debuggers etc. This is one reason why I use them in preference
over PIC etc.
>
> And for mid-range application, how AT91SAM(ATMEL) is better than
> LPC21XX(NXP)?
Which is better a Ferrari or a Volswagen? Well if you want to drive around the
roads near me, then the Volkswagen is better.
They are different, with different peripheral mixes and capabilities.
The SAM parts have peripheral DMA, which is noce, but the TWI (I2C)
implementation is very buggy.
>From what I have observed, the NXP support people are far better at
interacting with groups like this than Atmel are.
Ultimately the engineering effort will be similar to use each and things like
peripheral mix, and cost, will be determined by project requirements.
Reply by ●April 23, 20072007-04-23
Hi,
Can someone recommend a crystal for the AT91SAM7S?
I've also been unable to run down the KONY SM184-20 crystal found on the
AT91SAM7S256-EK board.
SM would be fine, I'd even settle for a short HC49-US through-hole model.
Thanks,
Alan KM6VV
Can someone recommend a crystal for the AT91SAM7S?
I've also been unable to run down the KONY SM184-20 crystal found on the
AT91SAM7S256-EK board.
SM would be fine, I'd even settle for a short HC49-US through-hole model.
Thanks,
Alan KM6VV
Reply by ●April 23, 20072007-04-23
--- In A..., Alan KM6VV wrote:
>
> Hi,
>
> Can someone recommend a crystal for the AT91SAM7S?
>
> I've also been unable to run down the KONY SM184-20 crystal found on
the
> AT91SAM7S256-EK board.
>
> SM would be fine, I'd even settle for a short HC49-US through-hole
model.
Alan,
You came to the right place. I am the guy who is responsible for
Atmel adding crystal characteristics to their data sheet. I am not an
expert in crystal oscillators, but they are not totally trivial so I
did some research on them. In addition to the frequency, you need to
specify the shunt capacitance and the ESR. The shunt capacitance is
the value that the crystal is calibrated to. Using a different value
will change the frequency. The ESR is a maximum value which if
exceeded may prevent the oscillator from starting. On page 505 of the
data sheet they list the values for these parameters. Allowed ESR is
a function of frequency so they have a brief table.
If you don't care much about the size, then you can easily find a
crystal that has a sufficiently low ESR. But if you want a smaller
part, say a 3.2 x 2.5 mm part like they use in cell phones, you will
have to get the vendor to spec a part for you. They are doing this
for my previous employer so it is not a big deal.
The table lists ESR in steps. It actually varies in a continuous
manner and they approved using a 60 ohm ESR crystal at the frequency
used on the eval board, 18.432 MHz.
The shunt capacitance given in the table is the value the chip
provides. If it is lower than the value needed for your crystal you
will need to add capcitors to the circuit to get the frequency right.
BTW, I seem to recall that Atmel designed this part with 20 pF across
the oscillator leads. So the data sheet may be wrong as it says 7 pF.
You might want to ask your sales person about that.
>
> Hi,
>
> Can someone recommend a crystal for the AT91SAM7S?
>
> I've also been unable to run down the KONY SM184-20 crystal found on
the
> AT91SAM7S256-EK board.
>
> SM would be fine, I'd even settle for a short HC49-US through-hole
model.
Alan,
You came to the right place. I am the guy who is responsible for
Atmel adding crystal characteristics to their data sheet. I am not an
expert in crystal oscillators, but they are not totally trivial so I
did some research on them. In addition to the frequency, you need to
specify the shunt capacitance and the ESR. The shunt capacitance is
the value that the crystal is calibrated to. Using a different value
will change the frequency. The ESR is a maximum value which if
exceeded may prevent the oscillator from starting. On page 505 of the
data sheet they list the values for these parameters. Allowed ESR is
a function of frequency so they have a brief table.
If you don't care much about the size, then you can easily find a
crystal that has a sufficiently low ESR. But if you want a smaller
part, say a 3.2 x 2.5 mm part like they use in cell phones, you will
have to get the vendor to spec a part for you. They are doing this
for my previous employer so it is not a big deal.
The table lists ESR in steps. It actually varies in a continuous
manner and they approved using a 60 ohm ESR crystal at the frequency
used on the eval board, 18.432 MHz.
The shunt capacitance given in the table is the value the chip
provides. If it is lower than the value needed for your crystal you
will need to add capcitors to the circuit to get the frequency right.
BTW, I seem to recall that Atmel designed this part with 20 pF across
the oscillator leads. So the data sheet may be wrong as it says 7 pF.
You might want to ask your sales person about that.
Reply by ●April 24, 20072007-04-24
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.
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.
Reply by ●April 24, 20072007-04-24
> 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
__________________________________________________
> 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
__________________________________________________
Reply by ●April 24, 20072007-04-24
--- 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.
>
> 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.
Reply by ●April 24, 20072007-04-24
> 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
__________________________________________________
> 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
__________________________________________________
Reply by ●April 24, 20072007-04-24
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
>
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
>
Reply by ●April 24, 20072007-04-24
--- 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.
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.
