AVR-Chat

--- In AVR-Chat@yahoogroups.com, dlc <dlc@...> wrote:
>
> I've been wondering about debugwire, perhaps I'll stick to tracing 
with 
> "printf"...
>

Boy I tell ya.

I was able to get it working, intermittently.
When it works, I can debug pretty well.  BUT.

After working with it for a while yesterday, I hit a point where 
things were happening that made NO sense.  Then I noticed that it was 
having problems in the program flow.

Let's say we just executed these lines:

 clr zh
 ldi zl,$01

Can anyone tell me what the Z register should read?
Would you guess $3F01?

You can imagine this has rather interesting consequences for 
subsequent execution.

As far as I can tell from running, the ZH register really does have 
$3F in it.  I also caught it when I init the stack pointer, which 
looks like this:

Bootload:
	ldi	TEMP,low(RAMEND)		; $04FF
	out	SPL,TEMP			;Init stackpointer
	ldi	TEMP,high(RAMEND)		;
	out	SPH,TEMP			;

At the end of this, SP was something like $01FF, and that was where 
it was storing the data.  RAMEND is properly defined, I haven't 
touched it, and it used to work!

I powered the target down, shut down studio, rebooted, etc, several 
times, and every time afterward, I got the same errors at the same 
points in the code!

I posted this to AVR@atmel.com, along with a  jpg of the screen, 
showing my just having executed the clr zh, ldi zl,$01, with that and 
the contents of Z circled, and they replied, pointing me to a couple 
of useless FAQ articles, and closed the bug report.

I'm really pretty pissed at this point. 
I just spent $300 on a debugger, and I'm spending 80% of my time 
wrestling with the debugger.

What's it going to take to get workable debugging tools?
Do we need to show up and picket their booth at the next embedded 
systems conference?