Re: [AVaRICE-user] AT90CAN32, dragon and avarice: 0x0 <__vectors>: rjmp .-2 endless loop

[Wolfgang R. <wr...@ti...>]

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 <wr...@ti...>:

> 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 <wr...@ti...>:
> 
> > 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 :-)