AVR-Chat

Could we also do a timer test?
 
Is 10uSec really 10uSec?
 
 

[Non-text portions of this message have been removed]

On Mon, Feb 23, 2009 at 12:54 PM, David Appleton <englsprogeny@yahoo.com> wrote:
>
>
> Could we also do a timer test?
> Is 10uSec really 10uSec?

The problem is that you have nothing to reference it to, other than
the crystal, unless you have some independent external timebase.

A 60Hz line signal would do, 32kHz crystal...

The WDT is good for detecting the system running slower than it
should, but not for faster!

With an external timebase, you can put a window around it, and if the
pulse isn't present, or the period seems abnormal, then go into an
appropriate "fail safe" mode.

David VanHorn wrote:
> On Mon, Feb 23, 2009 at 12:54 PM, David Appleton <englsprogeny@yahoo.com> wrote:
>>
>> Could we also do a timer test?
>> Is 10uSec really 10uSec?
> 
> The problem is that you have nothing to reference it to, other than
> the crystal, unless you have some independent external timebase.
> 
> A 60Hz line signal would do, 32kHz crystal...
> 
> The WDT is good for detecting the system running slower than it
> should, but not for faster!

You mean like this?

http://focus.ti.com/lit/ds/symlink/tps3813k33.pdf

Robert

-- 
http://www.aeolusdevelopment.com/

  From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time?  37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live....
we currently have stock."

>> The WDT is good for detecting the system running slower than it
>> should, but not for faster!
>
> You mean like this?
>
> http://focus.ti.com/lit/ds/symlink/tps3813k33.pdf

Only if you never want to put the AVR to sleep to save
batteries.

68HC11 handled this case far better than other parts
I've used.  It has a specific "Clock Operating Properly; COP"
section.  The COP has its own clock source.  If the COP
detects the main Osc. has failed it generates a clock and
an interrupt.  You are then in a "limp a long" mode so you can
do a clean shutdown.




-- 
http://www.wearablesmartsensors.com/
http://www.softwaresafety.net/
http://www.designer-iii.com/
http://www.unusualresearch.com/

Bob Paddock wrote:
>>> The WDT is good for detecting the system running slower than it
>>> should, but not for faster!
>> You mean like this?
>>
>> http://focus.ti.com/lit/ds/symlink/tps3813k33.pdf
> 
> Only if you never want to put the AVR to sleep to save
> batteries.

So more like one of these

http://www.atmel.com/dyn/resources/prod_documents/doc4755.pdf

Mind you, for the originally referenced application entering sleep mode 
would have been an error anyway.

Or you could build one with a small micro.

Robert

-- 
http://www.aeolusdevelopment.com/

  From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time?  37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live....
we currently have stock."

I know this sounds a simple "of course" type question but:

I could have the controller output a 10uSec pulse and read it with a
logic analyzer to verify that the timing is correct.

[This verifies that the caps are correct for the oscillator]

Correct assumption?



--- In AVR-Chat@yahoogroups.com, David VanHorn <microbrix@...> wrote:
>
> On Mon, Feb 23, 2009 at 12:54 PM, David Appleton <englsprogeny@...>
wrote:

> >
> >
> > Could we also do a timer test?
> > Is 10uSec really 10uSec?
> 
> The problem is that you have nothing to reference it to, other than
> the crystal, unless you have some independent external timebase.
> 
> A 60Hz line signal would do, 32kHz crystal...
> 
> The WDT is good for detecting the system running slower than it
> should, but not for faster!
> 
> With an external timebase, you can put a window around it, and if the
> pulse isn't present, or the period seems abnormal, then go into an
> appropriate "fail safe" mode.
>

On Wed, Feb 25, 2009 at 7:16 AM, englsprogeny <englsprogeny@yahoo.com> wrote:
>
> I know this sounds a simple "of course" type question but:
>
> I could have the controller output a 10uSec pulse and read it with a
> logic analyzer to verify that the timing is correct.
>
> [This verifies that the caps are correct for the oscillator]
>
> Correct assumption?

No..

1: It only verifies the operation at that moment.  Note in the train
crash, the board had been operating normally for some time, then it
switched to overtone operation due to some unknown factor.

2: Operating frequency is a poor indicator of proper cap values.
Crystals are HARD to pull off frequency.
If you're significantly off frequency, something is WAY wrong..

>
> I know this sounds a simple "of course" type question but:
>
> I could have the controller output a 10uSec pulse and read it with a
> logic analyzer to verify that the timing is correct.

  If I were concerned I would make sure that the chip is "rail-to-rail"
powering the oscillator and simply put a scope on the oscillator output.

DLC

> [This verifies that the caps are correct for the oscillator]

> Correct assumption?
>
>
>
> --- In AVR-Chat@yahoogroups.com, David VanHorn <microbrix@...> wrote:
>>
>> On Mon, Feb 23, 2009 at 12:54 PM, David Appleton <englsprogeny@...>
> wrote:
>> >
>> >
>> > Could we also do a timer test?
>> > Is 10uSec really 10uSec?
>>
>> The problem is that you have nothing to reference it to, other than
>> the crystal, unless you have some independent external timebase.
>>
>> A 60Hz line signal would do, 32kHz crystal...
>>
>> The WDT is good for detecting the system running slower than it
>> should, but not for faster!
>>
>> With an external timebase, you can put a window around it, and if the
>> pulse isn't present, or the period seems abnormal, then go into an
>> appropriate "fail safe" mode.
>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


-- 
Dennis Clark
TTT Enterprises

On Wed, Feb 25, 2009 at 10:32 AM, Dennis Clark <dlc@frii.com> wrote:
>
>>
>> I know this sounds a simple "of course" type question but:
>>
>> I could have the controller output a 10uSec pulse and read it with a
>> logic analyzer to verify that the timing is correct.
>
>  If I were concerned I would make sure that the chip is "rail-to-rail"
> powering the oscillator and simply put a scope on the oscillator output.

I'm not sure what you meant here..

If you don't have the "rail to rail" oscillator selected, (CKOPT
fuse), then you are BEGGING INSISTENTLY for trouble.
Hanging a scope probe on either crystal lead, adds at least 10pF to
the loading, so it's entirely possible to have things working properly
BECAUSE the scope probe is there.

One "cheat" I've used to check frequency is to probe the crystal can,
since it's usually not grounded (though it should be) and it's
capacitance helps hide the probe's loading from the circuit.

Setting up an output that's derived from the clock via a hardware
timer is ok, but you have to be able to measure that with high
precision.

Still, this says nothing about drive level, or oscillation margin, and
since crystals are inherently hard to "pull" off frequency, it tells
you very little about the loading cap values.

One way to get at the crystal frequency without "touching" the
circuit, is to use a shortwave receiver with BFO.
The oscillator will radiate some, enough that you can receive it.  You
need to know how to set up the BFO, but you can practice on tuning in
WWV (or your local time standard broadcast) since their frequencies
are highly accurate.

> On Wed, Feb 25, 2009 at 10:32 AM, Dennis Clark <dlc@frii.com> wrote:
>>
>>>
>>> I know this sounds a simple "of course" type question but:
>>>
>>> I could have the controller output a 10uSec pulse and read it with a
>>> logic analyzer to verify that the timing is correct.
>>
>>  If I were concerned I would make sure that the chip is "rail-to-rail"
>> powering the oscillator and simply put a scope on the oscillator output.
>
> I'm not sure what you meant here..
>
> If you don't have the "rail to rail" oscillator selected, (CKOPT
> fuse), then you are BEGGING INSISTENTLY for trouble.
> Hanging a scope probe on either crystal lead, adds at least 10pF to
> the loading, so it's entirely possible to have things working properly
> BECAUSE the scope probe is there.

  The option is there to NOT have that fuse programmed and your part will
work fine, usually, and on occasion go into the weeds for no apparent
reason.  I've spaced that fuse and scratched my head before.

> One "cheat" I've used to check frequency is to probe the crystal can,
> since it's usually not grounded (though it should be) and it's
> capacitance helps hide the probe's loading from the circuit.
>
> Setting up an output that's derived from the clock via a hardware
> timer is ok, but you have to be able to measure that with high
> precision.

  Some parts have the option of spitting the clock out an IO pin (MEGA168
for instance) and you can use that to clock other parts in the circuit,
or to check the clock frequency if that is your desire.

DLC

> Still, this says nothing about drive level, or oscillation margin, and
> since crystals are inherently hard to "pull" off frequency, it tells
> you very little about the loading cap values.
>
> One way to get at the crystal frequency without "touching" the
> circuit, is to use a shortwave receiver with BFO.
> The oscillator will radiate some, enough that you can receive it.  You
> need to know how to set up the BFO, but you can practice on tuning in
> WWV (or your local time standard broadcast) since their frequencies
> are highly accurate.
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


-- 
Dennis Clark
TTT Enterprises

>  The option is there to NOT have that fuse programmed and your part will
> work fine, usually, and on occasion go into the weeds for no apparent
> reason.  I've spaced that fuse and scratched my head before.

Exactly.. Using the "low power mode" is the default, and I don't know
why Atmel did it that way, but that's what we're stuck with.
In the files area, is a little program I wrote called "Fuser", which
uses a tiny to fix the fuses on systems that accidentally got deployed
with the default on the CKOPT fuse.

>  Some parts have the option of spitting the clock out an IO pin (MEGA168
> for instance) and you can use that to clock other parts in the circuit,
> or to check the clock frequency if that is your desire.

That's cool, since there's a buffer between the probe and the actual oscillator.

I want to be really clear, that measuring the frequency of oscillation
is nowhere near good enough to ensure proper operation of the
oscillator.

>>  The option is there to NOT have that fuse programmed and your part will
>> work fine, usually, and on occasion go into the weeds for no apparent
>> reason.  I've spaced that fuse and scratched my head before.
>
> Exactly.. Using the "low power mode" is the default, and I don't know
> why Atmel did it that way, but that's what we're stuck with.
> In the files area, is a little program I wrote called "Fuser", which
> uses a tiny to fix the fuses on systems that accidentally got deployed
> with the default on the CKOPT fuse.
>
>>  Some parts have the option of spitting the clock out an IO pin (MEGA168
>> for instance) and you can use that to clock other parts in the circuit,
>> or to check the clock frequency if that is your desire.
>
> That's cool, since there's a buffer between the probe and the actual
> oscillator.
>
> I want to be really clear, that measuring the frequency of oscillation
> is nowhere near good enough to ensure proper operation of the
> oscillator.

  Indeed.  The oscillator can be affected by the dynamics of the moment in
your circuit.  Motor noise, ground bounce, power brownout, static zap
and other even less understood issues.  Bomb-proofing your design is a
major part of the voodoo we (hopefully) get paid the big bucks to do.

DLC
-- 
Dennis Clark
TTT Enterprises

>  Indeed.  The oscillator can be affected by the dynamics of the moment in
> your circuit.  Motor noise, ground bounce, power brownout, static zap
> and other even less understood issues.  Bomb-proofing your design is a
> major part of the voodoo we (hopefully) get paid the big bucks to do.

Exactly!

"works" for a hobby project is very different from "works" for a
production run of 1,000,000 devices.