Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Thread

Re: Debugging a ATmega48V - what's going on?

Re: Debugging a ATmega48V - what's going on?

2007-11-12 by Richard Cooke

Dennis,

I've been trying to come up with assumptions to test.  The thing that
really is frustrating is the firmware works on one board but not the
new ones so I think that the firmware can be eliminated as the source
of the error.

Thanks,

Richard Cooke

--- In AVR-Chat@yahoogroups.com, dlc@... wrote:
Show quoted textHide quoted text
>
> I have only a generic response to make here.  To paraphrase Sherlock
> Holmes a bit:
> 
> "If your facts make no sense, examine your assumptions, one or more of
> them is incorrect."
> 
> So, check your assumptions, even the most trivial could cause you this
> kind of headache.
> 
> DLC
> --
> Dennis Clark
> 
> > 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
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>

Re: Debugging a ATmega48V - what's going on?

2007-11-12 by Richard Cooke

Hi David,

I built up two new boards - one had an ATmega48V from the batch that
was the same as the Ver1 board and the other was from a different batch.

Thanks, 

Richard Cooke

--- In AVR-Chat@yahoogroups.com, David Kelly <dkelly@...> wrote:
Show quoted textHide quoted text
>
> On Mon, Nov 12, 2007 at 08:02:13PM -0000, Richard Cooke wrote:
> > Dennis,
> > 
> > I've been trying to come up with assumptions to test.  The thing that
> > really is frustrating is the firmware works on one board but not the
> > new ones so I think that the firmware can be eliminated as the source
> > of the error.
> 
> New boards using new chips? Do you have any new old stock from the prior
> batch of boards? Sometimes chips change. Search the errata notices at
> Atmel.com.
> 
> -- 
> David Kelly N4HHE, dkelly@...
> ========================================================================
> Whom computers would destroy, they must first drive mad.
>

Re: [AVR-Chat] Debugging a ATmega48V - what's going on?

2007-11-12 by dlc@frii.com

I have only a generic response to make here.  To paraphrase Sherlock
Holmes a bit:

"If your facts make no sense, examine your assumptions, one or more of
them is incorrect."

So, check your assumptions, even the most trivial could cause you this
kind of headache.

DLC
--
Dennis Clark
Show quoted textHide quoted text
> 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
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

Re: [AVR-Chat] Re: Debugging a ATmega48V - what's going on?

2007-11-12 by David Kelly

On Mon, Nov 12, 2007 at 08:02:13PM -0000, Richard Cooke wrote:
> Dennis,
> 
> I've been trying to come up with assumptions to test.  The thing that
> really is frustrating is the firmware works on one board but not the
> new ones so I think that the firmware can be eliminated as the source
> of the error.

New boards using new chips? Do you have any new old stock from the prior
batch of boards? Sometimes chips change. Search the errata notices at
Atmel.com.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

Re: [AVR-Chat] Re: Debugging a ATmega48V - what's going on?

2007-11-13 by Phillip Vogel

Richard Cooke wrote:
>
> Hi David,
>
> I built up two new boards - one had an ATmega48V from the batch that
> was the same as the Ver1 board and the other was from a different batch.
>
> Thanks,
>
> Richard Cooke
>
> --- In AVR-Chat@yahoogroups.com <mailto:AVR-Chat%40yahoogroups.com>, 
> David Kelly <dkelly@...> wrote:
> >
> > On Mon, Nov 12, 2007 at 08:02:13PM -0000, Richard Cooke wrote:
> > > Dennis,
> > >
> > > I've been trying to come up with assumptions to test. The thing that
> > > really is frustrating is the firmware works on one board but not the
> > > new ones so I think that the firmware can be eliminated as the source
> > > of the error.
> >
> > New boards using new chips? Do you have any new old stock from the prior
> > batch of boards? Sometimes chips change. Search the errata notices at
> > Atmel.com.
> >
> > --
> > David Kelly N4HHE, dkelly@...
> > ========================================================================
> > Whom computers would destroy, they must first drive mad.
> >
>
>  
How about take a working Ver1 board and transfer components (like the 
mega48V) to a Ver2 board? It *IS* possible to have bad parts.

Also, are you absolutely sure that the boards are good? Were they 
netlist tested or golden-board tested? If the latter, it is possible 
that the entire batch of Ver2 boards has the same error.

What is controlled by the pins in question? What happens if you comment 
out *both* lines?

Have you tried replacing the power supply with something super stable 
and low impedance?

Hang in there.

-- 
Phillip Vogel
Bartal Design Group, Inc.
318 Marlboro Road Englewood, NJ 07631-1416
Phone: 201-567-1343      Fax: 201-568-2891
Cell: 201-232-5208    
mailto:phillip@bartal.com  http://www.VisualConductor.com



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

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.