Yahoo Groups archive

AVR-Chat

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

Thread

Re: A day in the life

Re: A day in the life

2004-01-28 by fnatmed

--- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@c...> wrote:
> 
> Just for laughs, I thought it would be interesting to actually log 
what 
> happens in an actual day of debugging.

<snippage>

> Similar problems happen in simulation, so I don't think that the 
ICE is 
> involved, at least not directly.
> Also, we see similar problems on multiple computers, and all recent 
(last 
> couple years) versions of studio.
> I see the same problems on my laptop with a transmeta Crusoe 700 
mhz 
> processor, and my XP pro 2GHz system.

Planning on switching to PICs are we ?  :P  heh heh

Seriously, that sounds awful.  How are major projects developed with 
AVR if the tools couse this much pain ?  Maybe they use IAR and C-
Spy, $pricey$ as that is :(

Dean.

A day in the life

2004-01-28 by Dave VanHorn

Just for laughs, I thought it would be interesting to actually log what 
happens in an actual day of debugging.
Here's yesterday's 12 hour session, debugging a M8 project, using the 
latest studio, and ICE-50, on a 2 ghz win-98 machine with 256m of ram.
I did not log how many issues happened in one event, for example if one or 
20 old breakpoints came back in one event, then that's still one event.


Old breakpoints come back: 8
This is where a breakpoint, or many breakpoints that I had previously 
cleared, come back on their own.
Double-clicking on the BP twice, usually clears the problem. Once 
apparently does nothing.

Tossed breakpoints: 5
This is where I set a breakpoint, did a build and run, and the breakpoint 
vanished.

Can't set breakpoints: 2
This is where, for unknown reasons, I am unable to set a breakpoint, by 
double-clicking on the source.
Sometimes F9 will work where the mouse won't, but frequently the only 
solution is to shut down studio, and reload.

Sticky breakpoints: 3
This is where I can't clear a breakpoint. Sometimes trying again will work, 
sometimes it takes a reload.

Won't run from F5: 4
Like above, sometimes F5 just dosen't GO. Selecting run from the toolbar 
usually works, but sometimes a reload is needed.

Skip over code: 1
This is where an F11 results in the pointer going anywhere below the next 
instruction. In this case, it went a couple pages past.

Ghostpoints: 2
These are a little different from old breakpoints back.. In this case, the 
emulator stops at a point where a BP used to be, but there is no BP shown.
Double-clicking on this point twice, usually clears the ghostpoint.

Run to cursor ignored: 1
This is where I hit "run to cursor", and end up way later, at a breakpoint.

Ignored Breakpoint: 1
This is where the emulator ran right past a breakpoint.

"Lost in space": 1
This one is tough to describe, because it's hard to believe it when it 
starts to happen.
Suddenly, really wild results, totally unpredictable execution, and the 
only cure is a reload.



Total anomalies: 28, for an average of less than 30 minutes use between 
problems.
Many of the problems necessitate a total shutdown and restart of studio.
Of course in each case, I am deep inside a problem, and have spent 
significant time setting up the conditions to test a routine, only to have 
my concentration trashed, or my session trashed.

Similar problems happen in simulation, so I don't think that the ICE is 
involved, at least not directly.
Also, we see similar problems on multiple computers, and all recent (last 
couple years) versions of studio.
I see the same problems on my laptop with a transmeta Crusoe 700 mhz 
processor, and my XP pro 2GHz system.

Re: [AVR-Chat] Re: A day in the life

2004-01-28 by Dave VanHorn

>
>Planning on switching to PICs are we ?  :P  heh heh

I see it more as a testament to how much I despise the internal 
"architecture" of the pic.


>Seriously, that sounds awful.  How are major projects developed with  AVR 
>if the tools couse this much pain ?

That is a question I have asked myself a lot, over the last couple years.
My experience with studio 3.2-ish, and the ICE-200 was absolutely stellar.
Big projects cranked out fast, sim worked flawlessly, emulator was also 
flawless.
Early experience on the ICE-50 and early studio 4 was good. There were 
problems, but it was an early beta.
Then, right around the time they released S4, I think things went downhill.
I started having pretty bizarre problems, like the middle two bits in the 
ADC output reversed.. IE: 76534210



>Maybe they use IAR and C-Spy, $pricey$ as that is :(

We aren't working in C, but it wouldn't matter.

Re: [AVR-Chat] Re: A day in the life

2004-01-29 by Brian Dean

On Wed, Jan 28, 2004 at 11:52:18AM -0500, Dave VanHorn wrote:

> >Seriously, that sounds awful.  How are major projects developed
> >with AVR if the tools couse this much pain ?

> That is a question I have asked myself a lot, over the last couple
> years.  My experience with studio 3.2-ish, and the ICE-200 was
> absolutely stellar.

Come on over to the dark side, Dave - FreeBSD.

Find a spare system and load up the latest FreeBSD 4.9-RELEASE
Download that from here:

	http://www.freebsd.org/

To install avr-gcc:

	cd /usr/ports/devel/avr-gcc && make install

To install avrdude:

	cd /usr/ports/devel/avrdude && make install

To install avarice:

	cd /usr/ports/devel/avarice && make install

To install avr-gdb;

	cd /usr/ports/devel/avr-gdb && make install

To install a pretty good simulator:

	cd /usr/ports/devel/simulavr && make install

No fuss.

Grab a JTAGICE and a manual on the GNU Debugger (assuming you are new
at that) and you're good to go.

Also, I get the feeling you're an assembler person - the GNU assembler
works fine with the AVR including native assembler macro support, or
if you choose, you can preprocess the assembler files with the C
preprocessor and use C #defines and macros instead or in addition to.

Unfortunately, since the Atmel ICE products like the ICE-200 are
closed spec, there are no open source tools that can use them, to the
best of my knowledge.  That may be a show stopper for you.  But the
JTAGICE works well in combination with avarice and gdb, at least I
haven't had any problems with it at all.  I just used it the other day
to track down a particularly elusive memory overwrite bug.  I usually
only pull out the JTAGICE when debugging with printf() or tracking
program progress and state via carefully placed port pin changes and
monitoring with a scope fails to produce the desired results.  And
everytime I use the JTAGICE, I ask myself, "why don't I use this more
- it works great?".

-Brian
-- 
Brian Dean, bsd@bdmicro.com
BDMICRO - Maker of the MAVRIC ATmega128 Dev Board
http://www.bdmicro.com/

Re: [AVR-Chat] Re: A day in the life

2004-01-29 by samperi@ampertronics.com.au

At 10:32 PM 28/01/04 -0500, you wrote:
>everytime I use the JTAGICE, I ask myself, "why don't I use this more
>- it works great?".

Poor old (HAIRLESS) Dave is working with the Mega8 if I'm
not mistaken on this project. No JTAGICE for it.

Regards

John Samperi

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

Re: [AVR-Chat] Re: A day in the life

2004-01-29 by Dave VanHorn

>
>Come on over to the dark side, Dave - FreeBSD.
>
>Find a spare system and load up the latest FreeBSD 4.9-RELEASE
>Download that from here:
>
>         http://www.freebsd.org/
>
>To install avr-gcc:
>         cd /usr/ports/devel/avr-gcc && make install
>
>To install avrdude:
>         cd /usr/ports/devel/avrdude && make install
>
>To install avarice:
>         cd /usr/ports/devel/avarice && make install
>
>To install avr-gdb;
>         cd /usr/ports/devel/avr-gdb && make install
>
>To install a pretty good simulator:
>         cd /usr/ports/devel/simulavr && make install
>
>No fuss.
>Grab a JTAGICE and a manual on the GNU Debugger (assuming you are new at 
>that) and you're good to go.
>
>Also, I get the feeling you're an assembler person

Bingo. I feel the need, the need for SPEED! :)


>Unfortunately, since the Atmel ICE products like the ICE-200 are
>closed spec, there are no open source tools that can use them, to the
>best of my knowledge.  That may be a show stopper for you.  But the
>JTAGICE works well in combination with avarice and gdb, at least I
>haven't had any problems with it at all.  I just used it the other day
>to track down a particularly elusive memory overwrite bug.

Speaking of that, I do wish that atmel hadn't decided to make the registers 
available as ram.
I'm on the trail now, of what may be a bad ST Z,temp into register space.
Does that platform allow breaking on write to ram or register?
IMHO, this is a MAJOR failing of all the existing AVR tools.

>  I usually
>only pull out the JTAGICE when debugging with printf() or tracking
>program progress and state via carefully placed port pin changes and
>monitoring with a scope fails to produce the desired results.  And
>everytime I use the JTAGICE, I ask myself, "why don't I use this more
>- it works great?".


That doesn't even resemble the question I ask myself every time the #@!$ 
thing crashes, tosses my breakpoints, etc,etc,etc,etc,etc...

Re: [AVR-Chat] Re: A day in the life

2004-01-29 by Dave VanHorn

At 04:43 PM 1/29/2004 +1100, samperi@ampertronics.com.au wrote:
>At 10:32 PM 28/01/04 -0500, you wrote:
> >everytime I use the JTAGICE, I ask myself, "why don't I use this more
> >- it works great?".
>
>Poor old (HAIRLESS) Dave is working with the Mega8 if I'm
>not mistaken on this project. No JTAGICE for it.

Unfortunately yes, but I have a number of other systems that DO have Jtag 
ports.
It's not a complete solution, but it may be at least a big step.

Hairless is not where I am, but Atmel isn't helping any.

Re: [AVR-Chat] Re: A day in the life

2004-01-29 by Brian Dean

On Thu, Jan 29, 2004 at 07:51:23AM -0500, Dave VanHorn wrote:

> Speaking of that, I do wish that atmel hadn't decided to make the
> registers available as ram.  I'm on the trail now, of what may be a
> bad ST Z,temp into register space.  Does that platform allow
> breaking on write to ram or register?  IMHO, this is a MAJOR failing
> of all the existing AVR tools.

I just did a quick test of that and was able to break on a watchpoint.
However it doesn't look like it supports hardware assisted
watchpoints.  This means that gdb interrupts execution after every
instruction and examines the specified address to see if it has
changed.  This is quite slow, and also, gdb can only tell when the
memory changes, not when it is read or rewritten with the same value
as it currently held.  I suspect this is more a failing of
avarice/avr-gdb than of the JTAGICE, however, I'm just guessing at
that.  If so, then it is possible that the avarice/avr-gdb folks will
figure out how to make the JTAGICE do hardware assisted watchpoints
which would be much much better as the target will run a full speed
and can break on read as well as write.

I do note that I am running a dated version of avarice, as would you
if you installed it on FreeBSD using the ports mechanism that I
mentioned earlier.  I've had a little bit of trouble getting later
versions of avarice to build so that I can update the FreeBSD port (I
am the FreeBSD maintainer of that port).  However, the older version
has been working fine for me so I haven't pursued that very
diligently.  Perhaps if there is the possibility of enhanced features
such as hardware watchpoints, I will see if I can get the newest
avarice updated into the FreeBSD ports tree.

-Brian
-- 
Brian Dean, bsd@bdmicro.com
BDMICRO - Maker of the MAVRIC ATmega128 Dev Board
http://www.bdmicro.com/

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.