AVR-Chat

Hi Guys,

I have a very weird problem with my Mega16 (DIP40) running a 16MHz
crystal (22pF loading caps).

Im trying to read incoming data on PIND.0 very rapidly (approx 150kHz)
and the chip just doesnt seem to work correctly. It works perfectly if
I use either PIND.7 or PIND.2 (the only other 2 pins I tried). But as
soon as I swap it back to using PIND.0 it stops working again.

Ive also assertained that the program works fine if I use an internal
8MHz oscillator instead of 16MHz crystal. So I think it might have
something to do with the fact that PIND.0 is right next to a crystal
pin. Could noise from the crystal pin be coupling to the data input
and corrupting the data stream somehow ? could this be happening
inside the Mega16 ? If so it is unfortunate that Atmel have placed the
 RXD pin of the UART right next to the crystal pins.

Unfortunately I really do need to use a 16MHz crystal also, so merely
ignoring the problem and using a slower oscillator will not work !

WOULD APPRECIATE ANY SUGGESTIONS !!!

Thanks
Hein B
Auckland, New Zealand.

kernels_nz wrote:

> Hi Guys,
> 
> I have a very weird problem with my Mega16 (DIP40) running a 16MHz
> crystal (22pF loading caps).
> 
> Im trying to read incoming data on PIND.0 very rapidly (approx 150kHz)
> and the chip just doesnt seem to work correctly. It works perfectly if
> I use either PIND.7 or PIND.2 (the only other 2 pins I tried). But as
> soon as I swap it back to using PIND.0 it stops working again.
> 
> Ive also assertained that the program works fine if I use an internal
> 8MHz oscillator instead of 16MHz crystal. So I think it might have
> something to do with the fact that PIND.0 is right next to a crystal
> pin. Could noise from the crystal pin be coupling to the data input
> and corrupting the data stream somehow ? could this be happening
> inside the Mega16 ? If so it is unfortunate that Atmel have placed the
>  RXD pin of the UART right next to the crystal pins.
> 
> Unfortunately I really do need to use a 16MHz crystal also, so merely
> ignoring the problem and using a slower oscillator will not work !
> 
> WOULD APPRECIATE ANY SUGGESTIONS !!!
> 

Please post your fuse settings for the osc / clk setup, also have you got all 
the VCC and Gnd pins connected ?

22pf is a little low for most HC49 crystals, more common is 27 or 33pf (30pf 
is the ideal)

-- 
Regards,

Kat.
---------------------------------------------------------------
  K.A.Q. Electronics     Website: www.kaqelectronics.dyndns.org
  IM: Yahoo: PinkyDwaggy MSN: katinka@kaqelectronics.dyndns.org
  For Everything Electronics 		   Phone: 0419 923 731
---------------------------------------------------------------


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.15.2/251 - Release Date: 4/02/2006

> I have a very weird problem with my Mega16 (DIP40) running a 16MHz
> crystal (22pF loading caps).

Try adding (if possible) a 10R resistor in series with the pin and a 18pF
capacitor to grund as close to the pin as possible.

>22pf is a little low for most HC49 crystals, more common is 27 or 33pf
>(30pf is the ideal)

I've always used 15pF without problems on all boards.

Best regards
Lasse Madsen

> I've always used 15pF without problems on all boards.

Sigh..

Where do you get these crystals with the appx 6pF loading spec?
Normally such crystals are rather expensive and hard to find. 

Have you checked your oscillator margin?

Do you <KNOW> that you don't have problems, or things just sort of 
seem to be working ok, more or less?



Unfortunately, there is a bit of design work required to get it right.

First, the crystal determines the cap values, in it's loading cap 
spec. If your crystal dosen't have a loading cap spec, then it's a 
series mode rock, and you shouldn't use it in a parallel mode circuit 
like this. It won't operate at the nameplate frequency since the 
parallel and series resonant points cannot be at the same frequency, 
and it may not even start up reliably in this mode.

Second, from the crystal's point of view, the caps are in series, so 
they need to be almost twice the value specified by the crystal. 
Almost, because there is always some amount of stray capacitance on 
the board. You can guess at 5pF and start there. CL = (2*Cs)-5 

Third, you need to check drive power, it is possible to damage or 
even shatter a crystal with too much drive.  This involves a 
measurement of drive current and crystal impedance, see data sheet. 
Power is of course I^2 * R where R is the crystal impedance at 
resonance. You can add a small value resistor in series with the 
drive pin, and measure voltage across it.

Fourth, it's always a good idea to do a margin check, which involves 
adding series resistance between the micro's output pin and the 
crystal. You adjust this value upward till the oscillator just starts.
This value should be at least three times the crystal's ESR value, 
and higher ratios are better.

With the AVR in particular, there is one more consideration, the 
CKOPT fuse should be programmed. The default (unprogrammed) state 
enables a low power "vittoz" mode oscillator that typically operates 
at about 1/2VCC amplitude, and will cause significant problems unless 
the crystal is specifically designed for this mode.

> Could noise from the crystal pin be coupling to the data input
> and corrupting the data stream somehow ? could this be happening
> inside the Mega16 ? If so it is unfortunate that Atmel have placed the
>  RXD pin of the UART right next to the crystal pins.

Far more likely that your input signal is disturbing the crystal.
If you haven't programmed the CKOPT fuse, then do so.

After that, see my other post on checking the oscillator design.

There are also possible layout issues, involving how the crystal caps 
return to the AVR's ground pin. They should do so on an isolated track 
that connects to system ground only at the AVR pin.

> Unfortunately I really do need to use a 16MHz crystal also, so merely
> ignoring the problem and using a slower oscillator will not work !

On a more mundane note, this may be a code problem, can you detail how 
it is that you're checking the pin?

Hi Guys, Thanks for all the suggestions, will check the fuses tonight
when I get home, I think the suggestion that the input is actually
affecting the crystal instead of the other way round sounds very valid.

Im only checking PIND.0 as general input, and im reasonably
experienced with AVR's , so dont believe it's a simple code problem.
As I said, using PIND.0 = dont work, any other one of the PIND pins
works fine. 

THANKS AGAIN ! GREAT SUGGESTIONS FROM EVERYONE !

Cheers
Hein B
Auckland, New Zealand.

--- In AVR-Chat@yahoogroups.com, "Dave VanHorn" <dvh@...> wrote:

>
> > Could noise from the crystal pin be coupling to the data input
> > and corrupting the data stream somehow ? could this be happening
> > inside the Mega16 ? If so it is unfortunate that Atmel have placed the
> >  RXD pin of the UART right next to the crystal pins.
> 
> Far more likely that your input signal is disturbing the crystal.
> If you haven't programmed the CKOPT fuse, then do so.
> 
> After that, see my other post on checking the oscillator design.
> 
> There are also possible layout issues, involving how the crystal caps 
> return to the AVR's ground pin. They should do so on an isolated track 
> that connects to system ground only at the AVR pin.
> 
> > Unfortunately I really do need to use a 16MHz crystal also, so merely
> > ignoring the problem and using a slower oscillator will not work !
> 
> On a more mundane note, this may be a code problem, can you detail how 
> it is that you're checking the pin?
>

Hi Ivan -- MORE INFORMATION !

Nope, using PIND.0 as general input, in fact, the plan is to use
PIND.0 as general input to detect the start condition on a DMX512
packet and then change it to to UART RX to receive the individual
packets after that.

What I have done so far is look for the start condition (PIND.0 low
for more than 80us) and just toggle one of the outputs everytime it
receives a start condition. Doing this on PIND.0 is very erratic!
changing the code only in such a way that I check any other pin, it
works perfectly.

Another thing worth mentioning . . . I have noticed that PIND.0 is
also starting to load my input signal for no apparent reason after a
while of operation. The input signal is buffered, output swing is GND
to 5V. After a while of running with this signal connected to PIND.0,
the output swing measured with my scope droops to GND to approx 2.5V

Im starting to think more and more that the input signal is affecting
the crystal clocking somehow, will try again tonite, and seperate them
 as far as possible and also check the fuses etc. as some of the other
guys suggested.

Thanks
Hein B
Auckland, New Zealand.

--- In AVR-Chat@yahoogroups.com, "Ivan Vernot" <ivernot@...> wrote:
>
> Hien,
> Just a thought.... PIND.0 is shared with RXD on a mega16 - you don't
have 
> the UART enabled while you are trying to read PIND.0? ;-)
> 
> HTH
> Ivan Vernot
> 
> 
> ----- Original Message ----- 
> From: "kernels_nz" <hein@...>
> To: <AVR-Chat@yahoogroups.com>
> Sent: Tuesday, February 07, 2006 8:19 AM
> Subject: [AVR-Chat] Re: Problem reading PIND.0 on Mega16 with 16MHz
Crystal
> 
> 
> > Hi Guys, Thanks for all the suggestions, will check the fuses tonight
> > when I get home, I think the suggestion that the input is actually
> > affecting the crystal instead of the other way round sounds very
valid.
> >
> > Im only checking PIND.0 as general input, and im reasonably
> > experienced with AVR's , so dont believe it's a simple code problem.
> > As I said, using PIND.0 = dont work, any other one of the PIND pins
> > works fine.
> >
> > THANKS AGAIN ! GREAT SUGGESTIONS FROM EVERYONE !
> >
> > Cheers
> > Hein B
> > Auckland, New Zealand.
> >
> > --- In AVR-Chat@yahoogroups.com, "Dave VanHorn" <dvh@> wrote:
> >>
> >> > Could noise from the crystal pin be coupling to the data input
> >> > and corrupting the data stream somehow ? could this be happening
> >> > inside the Mega16 ? If so it is unfortunate that Atmel have
placed the
> >> >  RXD pin of the UART right next to the crystal pins.
> >>
> >> Far more likely that your input signal is disturbing the crystal.
> >> If you haven't programmed the CKOPT fuse, then do so.
> >>
> >> After that, see my other post on checking the oscillator design.
> >>
> >> There are also possible layout issues, involving how the crystal caps
> >> return to the AVR's ground pin. They should do so on an isolated
track
> >> that connects to system ground only at the AVR pin.
> >>
> >> > Unfortunately I really do need to use a 16MHz crystal also, so
merely
> >> > ignoring the problem and using a slower oscillator will not work !
> >>
> >> On a more mundane note, this may be a code problem, can you
detail how

> >> it is that you're checking the pin?
> >>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>

Hien,
Just a thought.... PIND.0 is shared with RXD on a mega16 - you don't have 
the UART enabled while you are trying to read PIND.0? ;-)

HTH
Ivan Vernot


----- Original Message ----- 

From: "kernels_nz" <hein@mediflex.co.nz>
To: <AVR-Chat@yahoogroups.com>
Sent: Tuesday, February 07, 2006 8:19 AM
Subject: [AVR-Chat] Re: Problem reading PIND.0 on Mega16 with 16MHz Crystal


> Hi Guys, Thanks for all the suggestions, will check the fuses tonight
> when I get home, I think the suggestion that the input is actually
> affecting the crystal instead of the other way round sounds very valid.
>
> Im only checking PIND.0 as general input, and im reasonably
> experienced with AVR's , so dont believe it's a simple code problem.
> As I said, using PIND.0 = dont work, any other one of the PIND pins
> works fine.
>
> THANKS AGAIN ! GREAT SUGGESTIONS FROM EVERYONE !
>
> Cheers
> Hein B
> Auckland, New Zealand.
>
> --- In AVR-Chat@yahoogroups.com, "Dave VanHorn" <dvh@...> wrote:
>>
>> > Could noise from the crystal pin be coupling to the data input
>> > and corrupting the data stream somehow ? could this be happening
>> > inside the Mega16 ? If so it is unfortunate that Atmel have placed the
>> >  RXD pin of the UART right next to the crystal pins.
>>
>> Far more likely that your input signal is disturbing the crystal.
>> If you haven't programmed the CKOPT fuse, then do so.
>>
>> After that, see my other post on checking the oscillator design.
>>
>> There are also possible layout issues, involving how the crystal caps
>> return to the AVR's ground pin. They should do so on an isolated track
>> that connects to system ground only at the AVR pin.
>>
>> > Unfortunately I really do need to use a 16MHz crystal also, so merely
>> > ignoring the problem and using a slower oscillator will not work !
>>
>> On a more mundane note, this may be a code problem, can you detail how
>> it is that you're checking the pin?
>>
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Hein,
did you enabled the PIND.0 pull-up?

Regards

Jose

 --- kernels_nz <hein@mediflex.co.nz> escribió:

> Hi Ivan -- MORE INFORMATION !
> 
> Nope, using PIND.0 as general input, in fact, the
> plan is to use
> PIND.0 as general input to detect the start
> condition on a DMX512
> packet and then change it to to UART RX to receive
> the individual
> packets after that.
> 
> What I have done so far is look for the start
> condition (PIND.0 low
> for more than 80us) and just toggle one of the
> outputs everytime it
> receives a start condition. Doing this on PIND.0 is
> very erratic!
> changing the code only in such a way that I check
> any other pin, it
> works perfectly.
> 
> Another thing worth mentioning . . . I have noticed
> that PIND.0 is
> also starting to load my input signal for no
> apparent reason after a
> while of operation. The input signal is buffered,
> output swing is GND
> to 5V. After a while of running with this signal
> connected to PIND.0,
> the output swing measured with my scope droops to
> GND to approx 2.5V
> 
> Im starting to think more and more that the input
> signal is affecting
> the crystal clocking somehow, will try again tonite,
> and seperate them
>  as far as possible and also check the fuses etc. as
> some of the other
> guys suggested.
> 
> Thanks
> Hein B
> Auckland, New Zealand.
> 
> --- In AVR-Chat@yahoogroups.com, "Ivan Vernot"
> <ivernot@...> wrote:
> >
> > Hien,
> > Just a thought.... PIND.0 is shared with RXD on a
> mega16 - you don't
> have 
> > the UART enabled while you are trying to read
> PIND.0? ;-)
> > 
> > HTH
> > Ivan Vernot
> > 
> > 
> > ----- Original Message ----- 
> > From: "kernels_nz" <hein@...>
> > To: <AVR-Chat@yahoogroups.com>
> > Sent: Tuesday, February 07, 2006 8:19 AM
> > Subject: [AVR-Chat] Re: Problem reading PIND.0 on
> Mega16 with 16MHz
> Crystal
> > 
> > 
> > > Hi Guys, Thanks for all the suggestions, will
> check the fuses tonight
> > > when I get home, I think the suggestion that the
> input is actually
> > > affecting the crystal instead of the other way
> round sounds very
> valid.
> > >
> > > Im only checking PIND.0 as general input, and im
> reasonably
> > > experienced with AVR's , so dont believe it's a
> simple code problem.
> > > As I said, using PIND.0 = dont work, any other
> one of the PIND pins
> > > works fine.
> > >
> > > THANKS AGAIN ! GREAT SUGGESTIONS FROM EVERYONE !
> > >
> > > Cheers
> > > Hein B
> > > Auckland, New Zealand.
> > >
> > > --- In AVR-Chat@yahoogroups.com, "Dave VanHorn"
> <dvh@> wrote:
> > >>
> > >> > Could noise from the crystal pin be coupling
> to the data input
> > >> > and corrupting the data stream somehow ?
> could this be happening
> > >> > inside the Mega16 ? If so it is unfortunate
> that Atmel have
> placed the
> > >> >  RXD pin of the UART right next to the
> crystal pins.
> > >>
> > >> Far more likely that your input signal is
> disturbing the crystal.
> > >> If you haven't programmed the CKOPT fuse, then
> do so.
> > >>
> > >> After that, see my other post on checking the
> oscillator design.
> > >>
> > >> There are also possible layout issues,
> involving how the crystal caps
> > >> return to the AVR's ground pin. They should do
> so on an isolated
> track
> > >> that connects to system ground only at the AVR
> pin.
> > >>
> > >> > Unfortunately I really do need to use a 16MHz
> crystal also, so
> merely
> > >> > ignoring the problem and using a slower
> oscillator will not work !
> > >>
> > >> On a more mundane note, this may be a code
> problem, can you
> detail how
> > >> it is that you're checking the pin?
> > >>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> 
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
>     AVR-Chat-unsubscribe@yahoogroups.com
> 
>  
> 
> 
> 



	


	
		
___________________________________________________________ 
1GB gratis, Antivirus y Antispam 
Correo Yahoo!, el mejor correo web del mundo 
http://correo.yahoo.com.ar

Hi Jose,

No, the input signal was buffered with a 74HC244, so my highs were
high and my lows were 0. I did actually try enabling the pullup at one
stage, but it didnt make any difference. 

Further on, I started writing the code yesterday with 8M internal
oscillator just to start getting the code done, and it works fine on
PIND.0 

I checked the fuses in AVRSTUDIO and saw that CKOPT was not ticked .
.. (DOH) Havent tried changing it yet, but im sure it will work.

Thanks !

Hein B
Auckland, New Zealand.

--- In AVR-Chat@yahoogroups.com, Jose Fuentes <josecarlosfuentes@...>
wrote:

>
> Hein,
> did you enabled the PIND.0 pull-up?
> 
> Regards
> 
> Jose
> 
>  --- kernels_nz <hein@...> escribió:
> 
> > Hi Ivan -- MORE INFORMATION !
> > 
> > Nope, using PIND.0 as general input, in fact, the
> > plan is to use
> > PIND.0 as general input to detect the start
> > condition on a DMX512
> > packet and then change it to to UART RX to receive
> > the individual
> > packets after that.
> > 
> > What I have done so far is look for the start
> > condition (PIND.0 low
> > for more than 80us) and just toggle one of the
> > outputs everytime it
> > receives a start condition. Doing this on PIND.0 is
> > very erratic!
> > changing the code only in such a way that I check
> > any other pin, it
> > works perfectly.
> > 
> > Another thing worth mentioning . . . I have noticed
> > that PIND.0 is
> > also starting to load my input signal for no
> > apparent reason after a
> > while of operation. The input signal is buffered,
> > output swing is GND
> > to 5V. After a while of running with this signal
> > connected to PIND.0,
> > the output swing measured with my scope droops to
> > GND to approx 2.5V
> > 
> > Im starting to think more and more that the input
> > signal is affecting
> > the crystal clocking somehow, will try again tonite,
> > and seperate them
> >  as far as possible and also check the fuses etc. as
> > some of the other
> > guys suggested.
> > 
> > Thanks
> > Hein B
> > Auckland, New Zealand.
> > 
> > --- In AVR-Chat@yahoogroups.com, "Ivan Vernot"
> > <ivernot@> wrote:
> > >
> > > Hien,
> > > Just a thought.... PIND.0 is shared with RXD on a
> > mega16 - you don't
> > have 
> > > the UART enabled while you are trying to read
> > PIND.0? ;-)
> > > 
> > > HTH
> > > Ivan Vernot
> > > 
> > > 
> > > ----- Original Message ----- 
> > > From: "kernels_nz" <hein@>
> > > To: <AVR-Chat@yahoogroups.com>
> > > Sent: Tuesday, February 07, 2006 8:19 AM
> > > Subject: [AVR-Chat] Re: Problem reading PIND.0 on
> > Mega16 with 16MHz
> > Crystal
> > > 
> > > 
> > > > Hi Guys, Thanks for all the suggestions, will
> > check the fuses tonight
> > > > when I get home, I think the suggestion that the
> > input is actually
> > > > affecting the crystal instead of the other way
> > round sounds very
> > valid.
> > > >
> > > > Im only checking PIND.0 as general input, and im
> > reasonably
> > > > experienced with AVR's , so dont believe it's a
> > simple code problem.
> > > > As I said, using PIND.0 = dont work, any other
> > one of the PIND pins
> > > > works fine.
> > > >
> > > > THANKS AGAIN ! GREAT SUGGESTIONS FROM EVERYONE !
> > > >
> > > > Cheers
> > > > Hein B
> > > > Auckland, New Zealand.
> > > >
> > > > --- In AVR-Chat@yahoogroups.com, "Dave VanHorn"
> > <dvh@> wrote:
> > > >>
> > > >> > Could noise from the crystal pin be coupling
> > to the data input
> > > >> > and corrupting the data stream somehow ?
> > could this be happening
> > > >> > inside the Mega16 ? If so it is unfortunate
> > that Atmel have
> > placed the
> > > >> >  RXD pin of the UART right next to the
> > crystal pins.
> > > >>
> > > >> Far more likely that your input signal is
> > disturbing the crystal.
> > > >> If you haven't programmed the CKOPT fuse, then
> > do so.
> > > >>
> > > >> After that, see my other post on checking the
> > oscillator design.
> > > >>
> > > >> There are also possible layout issues,
> > involving how the crystal caps
> > > >> return to the AVR's ground pin. They should do
> > so on an isolated
> > track
> > > >> that connects to system ground only at the AVR
> > pin.
> > > >>
> > > >> > Unfortunately I really do need to use a 16MHz
> > crystal also, so
> > merely
> > > >> > ignoring the problem and using a slower
> > oscillator will not work !
> > > >>
> > > >> On a more mundane note, this may be a code
> > problem, can you
> > detail how
> > > >> it is that you're checking the pin?
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> >     AVR-Chat-unsubscribe@yahoogroups.com
> > 
> >  
> > 
> > 
> > 
> 
> 
> 
> 	
> 
> 
> 	
> 		
> ___________________________________________________________ 
> 1GB gratis, Antivirus y Antispam 
> Correo Yahoo!, el mejor correo web del mundo 
> http://correo.yahoo.com.ar
>

kernels_nz wrote:

>Another thing worth mentioning . . . I have noticed that PIND.0 is
>also starting to load my input signal for no apparent reason after a
>while of operation. The input signal is buffered, output swing is GND
>to 5V. After a while of running with this signal connected to PIND.0,
>the output swing measured with my scope droops to GND to approx 2.5V
>  
>

   Maybe a silly thought, but:  have you tried this with a different 
chip?  This loading issue makes it sound to me as if perhaps your AVR 
chip is damaged, particularly that something is wrong with the harware 
associated with PIND.0.

tom

Hi Tom, yup, have tried it with 3 different Mega16's, I actually
figured the first chip was faulty and labeled it as such by munching
it's pins and chucking it in the garbage, only to find the same thing
happen on 2 others (Gutted). Found that the problem was the CKOPT fuse
which I didnt burn, means the oscillator was running at only half VCC
as far as I can figure.

Cheers
Hein B
Auckland, New Zealand.

--- In AVR-Chat@yahoogroups.com, Thomas Keller <tkeller1@...> wrote:

>
> kernels_nz wrote:
> 
> >Another thing worth mentioning . . . I have noticed that PIND.0 is
> >also starting to load my input signal for no apparent reason after a
> >while of operation. The input signal is buffered, output swing is GND
> >to 5V. After a while of running with this signal connected to PIND.0,
> >the output swing measured with my scope droops to GND to approx 2.5V
> >  
> >
> 
>    Maybe a silly thought, but:  have you tried this with a different 
> chip?  This loading issue makes it sound to me as if perhaps your AVR 
> chip is damaged, particularly that something is wrong with the harware 
> associated with PIND.0.
> 
> tom
>

--- In AVR-Chat@yahoogroups.com, "kernels_nz" <hein@...> wrote:
>
> Hi Tom, yup, have tried it with 3 different Mega16's, I actually
> figured the first chip was faulty and labeled it as such by munching
> it's pins and chucking it in the garbage, only to find the same thing
> happen on 2 others (Gutted). Found that the problem was the CKOPT fuse
> which I didnt burn, means the oscillator was running at only half VCC
> as far as I can figure.


Now you understand the evil of the CKOPT fuse.
Isn't that FUN?