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

[Wolfgang R. <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 :-)
> 
> 



-- 
Wolfgang Rosner