AVR-Chat

Hi Folks,

I've run into a problem that has me pulling out my hair.  I'm using
the AVR Dragon and the latest version of AVR Studio to debug my
boards.  I have two versions let's all them Ver1 and Ver2.  The only
difference being the RF matching network.  Ver1 works fine.  If I use
the exact same firmware that works in Ver1 in Ver2 it will hang at a
spot that makes no sense.  

After working for quite a while, I discovered the offending code as
"PORTB.0 = 1;".  All I am doing is setting the PORTB.0 pin high but as
I single step through the code it will hang right here. So, the code
snippet looks like:

PORTD.7 = 1;  <-- this works
PORTB.0 = 1;  <-- hangs here

If I reverse the two lines to this: 

PORTB.0 = 1;  <-- now this works 
PORTD.7 = 1;  <-- debugger hangs here


This strange behavior doesn't occur with the Ver1 board, only with
Ver2.  I've checked (multiple times) to make sure that there are no
shorts.  I've checked the bare boards and everything looks good.

Does anybody have any ideas what I should try next?

Thanks,

Richard Cooke
Lake Forest, CA USA

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

From: "Richard Cooke" <rcooke@digitalwavelength.com>
To: <AVR-Chat@yahoogroups.com>
Sent: Monday, November 12, 2007 7:14 PM
Subject: [AVR-Chat] Debugging a ATmega48V - what's going on?


> Hi Folks,
>
> I've run into a problem that has me pulling out my hair.  I'm using
> the AVR Dragon and the latest version of AVR Studio to debug my
> boards.  I have two versions let's all them Ver1 and Ver2.  The only
> difference being the RF matching network.  Ver1 works fine.  If I use
> the exact same firmware that works in Ver1 in Ver2 it will hang at a
> spot that makes no sense.
>
> After working for quite a while, I discovered the offending code as
> "PORTB.0 = 1;".  All I am doing is setting the PORTB.0 pin high but as
> I single step through the code it will hang right here. So, the code
> snippet looks like:
>
> PORTD.7 = 1;  <-- this works
> PORTB.0 = 1;  <-- hangs here
>
> If I reverse the two lines to this:
>
> PORTB.0 = 1;  <-- now this works
> PORTD.7 = 1;  <-- debugger hangs here

A faulty flash memory location that loads and verifies OK, but doesn't work 
when the program runs?

Leon

Hi Leon,

I've thought of the "bad chip" as the problem but it occurs on two
different boards.  I had spent too much time on the new board I
decided to build up another one and test it.  Problem didn't go away
with the new board so the issue shouldn't be a bad chip and since the
firmware works on Ver1 it shouldn't be the firmware.  I just don't
know what else to try.

Thanks,

Richard Cooke

--- In AVR-Chat@yahoogroups.com, "Leon" <leon355@...> wrote:
>
> ----- Original Message ----- 
> From: "Richard Cooke" <rcooke@...>
> To: <AVR-Chat@yahoogroups.com>
> Sent: Monday, November 12, 2007 7:14 PM
> Subject: [AVR-Chat] Debugging a ATmega48V - what's going on?
> 
> 
> > Hi Folks,
> >
> > I've run into a problem that has me pulling out my hair.  I'm using
> > the AVR Dragon and the latest version of AVR Studio to debug my
> > boards.  I have two versions let's all them Ver1 and Ver2.  The only
> > difference being the RF matching network.  Ver1 works fine.  If I use
> > the exact same firmware that works in Ver1 in Ver2 it will hang at a
> > spot that makes no sense.
> >
> > After working for quite a while, I discovered the offending code as
> > "PORTB.0 = 1;".  All I am doing is setting the PORTB.0 pin high but as
> > I single step through the code it will hang right here. So, the code
> > snippet looks like:
> >
> > PORTD.7 = 1;  <-- this works
> > PORTB.0 = 1;  <-- hangs here
> >
> > If I reverse the two lines to this:
> >
> > PORTB.0 = 1;  <-- now this works
> > PORTD.7 = 1;  <-- debugger hangs here
> 
> A faulty flash memory location that loads and verifies OK, but
doesn't work 

> when the program runs?
> 
> Leon
>

Hi Bruce,

I don't think it can be the "Pin Change Interrupt" sources. The
firmware works on Ver1 boards.  I don't change a thing when I hook up
the boards to the Dragon.  The same code is used for both versions. 
Ver1 works while Ver2 hangs at PORTB.0 = 1.

Thanks,

Richard Cooke

--- In AVR-Chat@yahoogroups.com, Bruce Parham <obparham@...> wrote:
>
> Richard Cooke wrote:
> 
> > Hi Folks,
> > 
> > I've run into a problem that has me pulling out my hair.  I'm using
> > the AVR Dragon and the latest version of AVR Studio to debug my
> > boards.  I have two versions let's all them Ver1 and Ver2.  The only
> > difference being the RF matching network.  Ver1 works fine.  If I use
> > the exact same firmware that works in Ver1 in Ver2 it will hang at a
> > spot that makes no sense.  
> > 
> > After working for quite a while, I discovered the offending code as
> > "PORTB.0 = 1;".  All I am doing is setting the PORTB.0 pin high but as
> > I single step through the code it will hang right here. So, the code
> > snippet looks like:
> > 
> > PORTD.7 = 1;  <-- this works
> > PORTB.0 = 1;  <-- hangs here
> > 
> > If I reverse the two lines to this: 
> > 
> > PORTB.0 = 1;  <-- now this works 
> > PORTD.7 = 1;  <-- debugger hangs here
> > 
> > 
> > This strange behavior doesn't occur with the Ver1 board, only with
> > Ver2.  I've checked (multiple times) to make sure that there are no
> > shorts.  I've checked the bare boards and everything looks good.
> > 
> > Does anybody have any ideas what I should try next?
> > 
> > Thanks,
> > 
> > Richard Cooke
> > Lake Forest, CA USA
> >  
> 
> Hi Richard,
> 
> Both of those pins are listed as "Pin Change Interrupt" sources.
Have they

> somehow become unmasked?
> 
> Bruce
>

Richard Cooke wrote:

> Hi Folks,
> 
> I've run into a problem that has me pulling out my hair.  I'm using
> the AVR Dragon and the latest version of AVR Studio to debug my
> boards.  I have two versions let's all them Ver1 and Ver2.  The only
> difference being the RF matching network.  Ver1 works fine.  If I use
> the exact same firmware that works in Ver1 in Ver2 it will hang at a
> spot that makes no sense.  
> 
> After working for quite a while, I discovered the offending code as
> "PORTB.0 = 1;".  All I am doing is setting the PORTB.0 pin high but as
> I single step through the code it will hang right here. So, the code
> snippet looks like:
> 
> PORTD.7 = 1;  <-- this works
> PORTB.0 = 1;  <-- hangs here
> 
> If I reverse the two lines to this: 
> 
> PORTB.0 = 1;  <-- now this works 
> PORTD.7 = 1;  <-- debugger hangs here
> 
> 
> This strange behavior doesn't occur with the Ver1 board, only with
> Ver2.  I've checked (multiple times) to make sure that there are no
> shorts.  I've checked the bare boards and everything looks good.
> 
> Does anybody have any ideas what I should try next?
> 
> Thanks,
> 
> Richard Cooke
> Lake Forest, CA USA
>  

Hi Richard,

Both of those pins are listed as "Pin Change Interrupt" sources. Have they
somehow become unmasked?

Bruce

At 06:14 AM 13/11/2007, you wrote:
>The only difference being the RF matching network.

I would start looking around here then. Do the pins in question
control transmission? Does the board work without the Dragon
otherwise?

If it only stops working when the Dragon is connected, I would
suspect RF getting into the reset line and killing the comms.

Do you have a pull up resistor on the reset line? I know they say
it is not required but won't hurt trying it out. 10K or 4K7.

>After working for quite a while, I discovered the offending code as
>"PORTB.0 = 1;".  All I am doing is setting the PORTB.0 pin high but as
>I single step through the code it will hang right here.

Another thought, does VCC remain good when both pins go high? Too much
current being drawn and the BOD kicks in momentarily? The oscillator
stops or misses beats?


Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

Are those pins turning on some RF stuff that being differently matched might 
use more current?
Did you validate the new RF design some other way, so you really have no RF 
shorts (not just DC)?

If you power from the Dragon USB... anything above a certain power might 
turn it off.

Cat

_________________________________________________________________
Send a smile, make someone laugh, have some fun! Check out 
freemessengeremoticons.ca

Hi Folks,

First, I want to thank every one for their good suggestions in trying
to track down this bug.  Just goes to show you that two (or more)
heads are better than one.

John Samperi and Cat win the prize.  If either one of you is ever in
town lunch is on me.  Turns out John's suggestion lead me to measure
the Vcc and it did indeed fall to 1.3V (from 3.3V) as soon as I single
stepped to the offending line in the debugger.  I had run out of ideas
so I revisted the RF section per Cat's suggestion.  Turns out I made a
layout error and there was a short between the radio output and the
antenna.  Looking back at the entire episode it makes perfect sense -
the bug only appeared when the radio went into TX mode.  I just wasn't
smart enough to see it.

Turns out that Eagle will allow you to make a connection while laying
out the PCB even if the schematic doesn't.  I've just recently
switched to Eagle from Winboard so I'm still learning how it does
things.  Winboard wouldn't allow you to connect two components if they
weren't connected in the schematic.  Now I know so I'll be more
careful next time.

Thanks again for all of your help.  I'd still be staring at the board
without your help.

Richard Cooke
Lake Forest, CA USA 


--- In AVR-Chat@yahoogroups.com, "Cat C" <catalin_cluj@...> wrote:
>
> Are those pins turning on some RF stuff that being differently
matched might 
> use more current?
> Did you validate the new RF design some other way, so you really
have no RF 
> shorts (not just DC)?
> 
> If you power from the Dragon USB... anything above a certain power
might 

> turn it off.
> 
> Cat
> 
> _________________________________________________________________
> Send a smile, make someone laugh, have some fun! Check out 
> freemessengeremoticons.ca
>

> Turns out that Eagle will allow you to make a connection while laying
> out the PCB even if the schematic doesn't.  I've just recently
> switched to Eagle from Winboard so I'm still learning how it does
> things.

OH my that sucks enormously..

Look for a setting somewhere to prevent/allow/warn on design rule violations.
I use the old dos orcad, which I have set always to prevent violations.
I've only had what you describe happen once in more than 13 years
using this software.

PCB error aside, I think that there is an important lesson,
here. 

Applicaions don't just "hang". That is, totally stop. They
may appear to, by not executing code that you are
expecting. They may stop by sleeping.  Jumping to itself
(the jump statement is another).

But, when the evidence is that it really stops (without
sleeping, etc), then you need to look at "what can cause a
micro to genuinely stop"? Being held in reset is one. Power
drop is another. That is about all there is.

Its something important to remember.

Jim Wagner
Oregon Research Electronics
---------------------------------------------------------------
The Think Different Store
http://www.thinkdifferentstore.com/
For All Your Mac Gear
---------------------------------------------------------------

At 05:13 AM 14/11/2007, you wrote:
>John Samperi and Cat win the prize.  If either one of you is ever in
>town lunch is on me.
.................
>Lake Forest, CA USA

Sure, I'll pop in town any day now...just around the corner..LOL

Glad it's sorted out.

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

Richard,
As a long time user of Eagle (and its goofy arrogant German interface), I'd recommend that you always run the DRC (design rule check) before making your Gerbers.   It will warn if the board doesn't match the schematic; I can't tell you how many times I've caught something at the last minute.

Tim

  ----- Original Message ----- 
  From: Richard Cooke 
  To: AVR-Chat@yahoogroups.com 
  Sent: Tuesday, November 13, 2007 11:13 AM
  Subject: [AVR-Chat] Re: Debugging a ATmega48V - what's going on? - I found it!


  Hi Folks,

  First, I want to thank every one for their good suggestions in trying
  to track down this bug. Just goes to show you that two (or more)
  heads are better than one.

  John Samperi and Cat win the prize. If either one of you is ever in
  town lunch is on me. Turns out John's suggestion lead me to measure
  the Vcc and it did indeed fall to 1.3V (from 3.3V) as soon as I single
  stepped to the offending line in the debugger. I had run out of ideas
  so I revisted the RF section per Cat's suggestion. Turns out I made a
  layout error and there was a short between the radio output and the
  antenna. Looking back at the entire episode it makes perfect sense -
  the bug only appeared when the radio went into TX mode. I just wasn't
  smart enough to see it.

  Turns out that Eagle will allow you to make a connection while laying
  out the PCB even if the schematic doesn't. I've just recently
  switched to Eagle from Winboard so I'm still learning how it does
  things. Winboard wouldn't allow you to connect two components if they
  weren't connected in the schematic. Now I know so I'll be more
  careful next time.

  Thanks again for all of your help. I'd still be staring at the board
  without your help.

  Richard Cooke
  Lake Forest, CA USA 

  --- In AVR-Chat@yahoogroups.com, "Cat C" <catalin_cluj@...> wrote:
  >
  > Are those pins turning on some RF stuff that being differently
  matched might 
  > use more current?
  > Did you validate the new RF design some other way, so you really
  have no RF 
  > shorts (not just DC)?
  > 
  > If you power from the Dragon USB... anything above a certain power
  might 
  > turn it off.
  > 
  > Cat
  > 
  > __________________________________________________________
  > Send a smile, make someone laugh, have some fun! Check out 
  > freemessengeremoticons.ca
  >



   

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

--- In AVR-Chat@yahoogroups.com, "Richard Cooke" <rcooke@...> wrote:

> ... Eagle will allow you to make
> a connection while laying out the
> PCB even if the schematic doesn't.

I want to join Tim in saying that you really must use the Design Rule 
Checker.  Eagle won't actually "allow you to make a connection" that 
isn't in the schematic.  But, it will allow you to add a trace, which 
is a different thing.  Connections are "air-wires" that you remove by 
routing traces.  If you add a feature (such as a trace) directly, Eagle 
assumes you know what you're doing.  Use the DRC to have it check that 
the board will come out right.

Unlike Tim, however, I have never found a problem at the last minute 
with the DRC.  That's because I run it over and over again as I work up 
the design.  You might consider this also as it avoids having a whole 
bunch of stuff to deal with at the end.

Graham.

Hi Tim,

The crazy thing is I did run the DRC before sending in my Gerber
files.  I still don't know what happened.

Richard Cooke
Lake Forest, CA USA

--- In AVR-Chat@yahoogroups.com, "Tim Gilbert" <tim@...> wrote:
>
> Richard,
> As a long time user of Eagle (and its goofy arrogant German
interface), I'd recommend that you always run the DRC (design rule
check) before making your Gerbers.   It will warn if the board doesn't
match the schematic; I can't tell you how many times I've caught
something at the last minute.
> 
> Tim
> 
>   ----- Original Message ----- 
>   From: Richard Cooke 
>   To: AVR-Chat@yahoogroups.com 
>   Sent: Tuesday, November 13, 2007 11:13 AM
>   Subject: [AVR-Chat] Re: Debugging a ATmega48V - what's going on? -
I found it!

> 
> 
>   Hi Folks,
> 
>   First, I want to thank every one for their good suggestions in trying
>   to track down this bug. Just goes to show you that two (or more)
>   heads are better than one.
> 
>   John Samperi and Cat win the prize. If either one of you is ever in
>   town lunch is on me. Turns out John's suggestion lead me to measure
>   the Vcc and it did indeed fall to 1.3V (from 3.3V) as soon as I single
>   stepped to the offending line in the debugger. I had run out of ideas
>   so I revisted the RF section per Cat's suggestion. Turns out I made a
>   layout error and there was a short between the radio output and the
>   antenna. Looking back at the entire episode it makes perfect sense -
>   the bug only appeared when the radio went into TX mode. I just wasn't
>   smart enough to see it.
> 
>   Turns out that Eagle will allow you to make a connection while laying
>   out the PCB even if the schematic doesn't. I've just recently
>   switched to Eagle from Winboard so I'm still learning how it does
>   things. Winboard wouldn't allow you to connect two components if they
>   weren't connected in the schematic. Now I know so I'll be more
>   careful next time.
> 
>   Thanks again for all of your help. I'd still be staring at the board
>   without your help.
> 
>   Richard Cooke
>   Lake Forest, CA USA 
> 
>   --- In AVR-Chat@yahoogroups.com, "Cat C" <catalin_cluj@> wrote:
>   >
>   > Are those pins turning on some RF stuff that being differently
>   matched might 
>   > use more current?
>   > Did you validate the new RF design some other way, so you really
>   have no RF 
>   > shorts (not just DC)?
>   > 
>   > If you power from the Dragon USB... anything above a certain power
>   might 
>   > turn it off.
>   > 
>   > Cat
>   > 
>   > __________________________________________________________
>   > Send a smile, make someone laugh, have some fun! Check out 
>   > freemessengeremoticons.ca
>   >
> 
> 
> 
>    
> 
> [Non-text portions of this message have been removed]
>

Yes, I use it during the layout process as well but have learned two things:

1: automatically have Eagle include the date and file name on the actual board; 
2: always run ERC and DRC one more time before sending the files to the board house!  


Regards,

Tim Gilbert
JEM Innovation Inc.
303-926-9053 (office)
303-437-4342 (cell)
720-890-8582 (fax)
www.jeminnovation.com
www.pdksolutions.com

  ----- Original Message ----- 
  From: Graham Davies 
  To: AVR-Chat@yahoogroups.com 
  Sent: Tuesday, November 13, 2007 6:02 PM
  Subject: [AVR-Chat] Re: Debugging a ATmega48V - what's going on? - I found it!


  --- In AVR-Chat@yahoogroups.com, "Richard Cooke" <rcooke@...> wrote:

  > ... Eagle will allow you to make
  > a connection while laying out the
  > PCB even if the schematic doesn't.

  I want to join Tim in saying that you really must use the Design Rule 
  Checker. Eagle won't actually "allow you to make a connection" that 
  isn't in the schematic. But, it will allow you to add a trace, which 
  is a different thing. Connections are "air-wires" that you remove by 
  routing traces. If you add a feature (such as a trace) directly, Eagle 
  assumes you know what you're doing. Use the DRC to have it check that 
  the board will come out right.

  Unlike Tim, however, I have never found a problem at the last minute 
  with the DRC. That's because I run it over and over again as I work up 
  the design. You might consider this also as it avoids having a whole 
  bunch of stuff to deal with at the end.

  Graham.



   

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

Richard,
Are you sure the short is in the design files?  I've had numerous boards (usually production boards), that come back with unexpected shorts between traces.  These result from "under etching" at the board house, which is why they offer electrical testing.  

Of course, it's the only industry I can think of that charges extra if you want them to build it right!  Can you imagine ordering a pepperoni pizza; finding onions instead of pepperoni; and the waiter says "you didn't pay for 'ingredient inspection'"!

Regards,

Tim Gilbert
JEM Innovation Inc.
303-926-9053 (office)
303-437-4342 (cell)
720-890-8582 (fax)
www.jeminnovation.com
www.pdksolutions.com

  ----- Original Message ----- 
  From: Richard Cooke 
  To: AVR-Chat@yahoogroups.com 
  Sent: Tuesday, November 13, 2007 6:43 PM
  Subject: [AVR-Chat] Re: Debugging a ATmega48V - what's going on? - I found it!


  Hi Tim,

  The crazy thing is I did run the DRC before sending in my Gerber
  files. I still don't know what happened.

  Richard Cooke
  Lake Forest, CA USA

  --- In AVR-Chat@yahoogroups.com, "Tim Gilbert" <tim@...> wrote:
  >
  > Richard,
  > As a long time user of Eagle (and its goofy arrogant German
  interface), I'd recommend that you always run the DRC (design rule
  check) before making your Gerbers. It will warn if the board doesn't
  match the schematic; I can't tell you how many times I've caught
  something at the last minute.
  > 
  > Tim
  > 
  > ----- Original Message ----- 
  > From: Richard Cooke 
  > To: AVR-Chat@yahoogroups.com 
  > Sent: Tuesday, November 13, 2007 11:13 AM
  > Subject: [AVR-Chat] Re: Debugging a ATmega48V - what's going on? -
  I found it!
  > 
  > 
  > Hi Folks,
  > 
  > First, I want to thank every one for their good suggestions in trying
  > to track down this bug. Just goes to show you that two (or more)
  > heads are better than one.
  > 
  > John Samperi and Cat win the prize. If either one of you is ever in
  > town lunch is on me. Turns out John's suggestion lead me to measure
  > the Vcc and it did indeed fall to 1.3V (from 3.3V) as soon as I single
  > stepped to the offending line in the debugger. I had run out of ideas
  > so I revisted the RF section per Cat's suggestion. Turns out I made a
  > layout error and there was a short between the radio output and the
  > antenna. Looking back at the entire episode it makes perfect sense -
  > the bug only appeared when the radio went into TX mode. I just wasn't
  > smart enough to see it.
  > 
  > Turns out that Eagle will allow you to make a connection while laying
  > out the PCB even if the schematic doesn't. I've just recently
  > switched to Eagle from Winboard so I'm still learning how it does
  > things. Winboard wouldn't allow you to connect two components if they
  > weren't connected in the schematic. Now I know so I'll be more
  > careful next time.
  > 
  > Thanks again for all of your help. I'd still be staring at the board
  > without your help.
  > 
  > Richard Cooke
  > Lake Forest, CA USA 
  > 
  > --- In AVR-Chat@yahoogroups.com, "Cat C" <catalin_cluj@> wrote:
  > >
  > > Are those pins turning on some RF stuff that being differently
  > matched might 
  > > use more current?
  > > Did you validate the new RF design some other way, so you really
  > have no RF 
  > > shorts (not just DC)?
  > > 
  > > If you power from the Dragon USB... anything above a certain power
  > might 
  > > turn it off.
  > > 
  > > Cat
  > > 
  > > __________________________________________________________
  > > Send a smile, make someone laugh, have some fun! Check out 
  > > freemessengeremoticons.ca
  > >
  > 
  > 
  > 
  > 
  > 
  > [Non-text portions of this message have been removed]
  >



   

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

Hi Tim,

I doubled checked the files and the short is there.  Since this was a
prototype I didn't feel that I needed to spend the extra money on
having the board house do electrical testing.  Most of my designs
aren't "bleeding edge" so they have pretty wide gaps between
components and traces so I thought that even with under-etching I
wouldn't have a problem.

Richard Cooke
Lake Forest, CA USA

--- In AVR-Chat@yahoogroups.com, "Tim Gilbert" <tim@...> wrote:
>
> Richard,
> Are you sure the short is in the design files?  I've had numerous
boards (usually production boards), that come back with unexpected
shorts between traces.  These result from "under etching" at the board
house, which is why they offer electrical testing.  
> 
> Of course, it's the only industry I can think of that charges extra
if you want them to build it right!  Can you imagine ordering a
pepperoni pizza; finding onions instead of pepperoni; and the waiter
says "you didn't pay for 'ingredient inspection'"!

> 
> Regards,
> 
> Tim Gilbert
> JEM Innovation Inc.
> 303-926-9053 (office)
> 303-437-4342 (cell)
> 720-890-8582 (fax)
> www.jeminnovation.com
> www.pdksolutions.com
>

> Of course, it's the only industry I can think of that charges extra if you want them to build it right!  Can you imagine ordering a pepperoni pizza; finding onions instead of pepperoni; and the waiter says "you didn't pay for 'ingredient inspection'"!


DONT give them any ideas!   Fast food is close enough as is.  Pay for
what you ordered at window #1, at window #2 they hand you a sack of
something or other.


This is one reason I've stuck with good old dos orcad.  The DRC isn't
a post process, it's done right as you're laying the tracks. Unless
you explicitly turn it off, or to "warn", it simply won't let you do
something you shouldn't do.