Hi,
coming closer - basically works now
short story:
thou shalt not load your elf file with dragon
long story:
==============================
avr-gdb -x gdb.cmd
$ cat gdb.cmd
file timer.elf
target remote localhost:1212
# load timer.elf
layout split
# layout asm
# tui reg general
define ppio
x/64bx 0x800020
end
set $PIND=(char *)0x800029
set $PORTD=(char *)0x80002b
displ /x *$PORTD
displ /t $SREG
display /i $pc
break main
break __vector_15
==============================
the culprit was the third line
load timer.elf
which I uncommented now.
I inherited this gdb-command file from trials with simulavr, and it did
not cause any trouble with my debug sessions on atmega32 - neither over
dragon nor over chinese clone.
what still does not work is "info io_registers"
gdb appears to enter an endless loop, no signs of activity on dragon's
leds. I know I can inspect any IO register manually, but for a first
view "what's going on", some overall symbolic listing still would be
nice.
Am Sat, 18 Mar 2017 20:30:13 +0100
schrieb Wolfgang Rosner <[email protected]>:
> Hi,
>
> further test results:
> - Problem persists after dragon firmware update with AVR Studio 4.19
> - JTAG debug works with AVR Studio 4.19, dragon and AT90CAN32
> - I think the LED flash speed of the dragon is much faster on AVR
> Studio
>
> So I can exclude dragon hardware, dragon firmware and my minimum
> breadboard system as cause.
>
> Looks like the problems are in the linux tool chain for avr.
>
> Wolfgang
>
>
> Am Fri, 17 Mar 2017 21:04:13 +0100
> schrieb Wolfgang Rosner <[email protected]>:
>
> > Hello,
> >
> > I'd like to debug on an AT90CAN32 target on a bread board assembly.
> > My cheap chinese jtag did not accept this.
> >
> > The avarice manpage says
> > at90can32 (o)
> > o - Only supported by the JTAG ICE mkII and AVR Dragon device.
> >
> > So I purchased one of the famous dragon boards.
> >
> >
> > But still debug does not work.
> > I can connect, read, flash, fuse with avrdude and at least connect
> > and flash with avarice.
> >
> > But when it goes to debug, it takes alread quite long (~ 20 sec) for
> > avr-gdb to come up. Dragon's LED keep flashing during most of start
> > up time.
> >
> > When I try to run my code, it stucks in an endless loop:
> >
> > ======8<==================================
> > (gdb) ni
> > 0x00000000 in __vectors ()
> > 3: x/i $pc
> > => 0x0 <__vectors>: rjmp .-2 ; 0x0 <__vectors>
> > 2: /t $SREG = 0
> > 1: /x *$PORTD = 0x4
> > (gdb) ni
> > 0x00000000 in __vectors ()
> > 3: x/i $pc
> > ....
> > ======8<==================================
> >
> > Anything else than ni single stepping lets hang both avr-gdb and
> > avarice.
> > avr-gdb does not accept ctrl-C any more (at least not within
> > reasonable time).
> > Dragon LED's keep blinking at ~~ 2 Hz.
> > Looks like the endless loop is processed tremendously slow and stuff
> > is accumulated in some large buffer.
> >
> > I can stop avarice with ctrl-C and avr-gdb dies with it.
> > I have to reset OCDEN fuse manually, if I want to run code on the
> > device after that.
> > But I assume that's a symptom related to the forceful break, not
> > related to the root cause.
> >
> >
> >
> > When I compare the code from my elf file, I see different code at
> > 0x000 than a rjmp .-2
> >
> >
> > ======8<==================================
> >
> > :~/test/AVR/hello/timer$ avr-objdump -d timer.elf
> >
> > timer.elf: file format elf32-avr
> >
> >
> > Disassembly of section .text:
> >
> > 00000000 <__vectors>:
> > 0: 0c 94 4a 00 jmp 0x94 ; 0x94 <__ctors_end>
> > 4: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt>
> > 8: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt>
> > c: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt>
> > .....
> > ======8<==================================
> >
> >
> >
> > So from a beginners educated guess, the debugging machine seems to
> > write this endless loop code at the device start address but does
> > not complete other steps to setup successful debugging???
> >
> > The behaviour is the same with avarice 2.11 shipped with debian
> > jessie and with avarice 2.13 built from sourceforge sources.
> >
> >
> >
> > For a refernce point, I tried the dragon setup on an Atmega32 target
> > attached to a simple pollin board.
> > It still displays the slow setup and the slow single steps. But
> > after the first ni command, I get assembler and source code
> > displayed in my gdb as configured and the code is executed in
> > normal sequence.
> >
> > I also have the sticky OCDEN fuse after (regular) shutdown.
> >
> >
> > Compared to my first experience, a cheap 7€ chinese dongle on the
> > same target debugs at least 10 times faster than the genuine part.
> >
> > Google led me to
> > http://www.avrfreaks.net/comment/241039#comment-241039
> > "I think there's no debugging option except for the JTAGICE mkII
> > for those units..."
> >
> > But this statement conflicts the avarice man page compatibility
> > list.
> >
> >
> > Have I been trapped by some AVR marketing "feature"?
> > "Thou shalt not use cheap stuff where AVR does not make money from"?
> > Is it a silly beginners error?
> > Can it be an electric / EMC issue on my bread board assembly?
> > Or have I encountered a real bug?
> >
> >
> > Any help or hints are appreciated :-)
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
avarice-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/avarice-user
