Menu
▾
▴
Re: [AVaRICE-user] AT90CAN32, dragon and avarice: 0x0 <__vectors>: rjmp .-2 endless loop
|
From: Wolfgang R. <wr...@ti...> - 2017-03-19 09:11:47
|
Hi Knut,
have you relized my mail 10 minute after yours?
- it works now
- "load timer.elf" command was the culprit.
I still do not understand why and if it is desired / acceptable
behaviur. Still newbie in gdb.
I know from simulavr that "load timer.elf" transfers the binary to the
target which presumably is not required / desired / possible in avarice
setups.
"file timer.elf" suffices to get the source displayed in gdb.
So maybe we can stop here?
If not, I'll provide the infos you requested:
Am Sat, 18 Mar 2017 21:26:25 +0100
schrieb Knut Schwichtenberg <ks...@we...>:
> Hi Wolfgang,
>
> which version of avarice are you using?
This is from debian:
...$ avarice --version
AVaRICE version 2.11, Dec 22 2013 18:22:47
...$ apt-cache policy avarice
avarice:
Installiert: 2.11-1.1
Installationskandidat: 2.11-1.1
Versionstabelle:
*** 2.11-1.1 0
500 http://ftp5.gwdg.de/pub/linux/debian/debian/ jessie/main
amd64 Packages 100 /var/lib/dpkg/status
this I built from sourceforge sources, declared as "last"
(I didn't manage to display the svn source tree, but I did not try
hard.)
https://sourceforge.net/projects/avarice/files/avarice/avarice-2.13/avarice-2.13.tar.bz2/download
...$ avarice-2_13 --version
AVaRICE version 2.13, Mar 17 2017 16:54:25
> Check if version 2.13 is more appropriate.
Both version show the same behaviour
> Please decribe the Linux versions you are using of avr-gcc, avr-gdb,
> avrdude and avr-libc.
$ cat /etc/debian_version
8.4
...$ avr-gcc --version
avr-gcc (GCC) 4.8.1
...$ avr-gdb --version
GNU gdb (GDB) 7.7.1
$ dpkg --list | grep avr
avrdude 6.1-2
avr-libc 1:1.8.0+Atmel3.4.4-1
gcc-avr 1:4.8.1+Atmel3.4.4-2
gdb-avr 7.7-2
....
-------------------
HÄ???
avr-gdb displays a different version than dpkg?
$ which avr-gdb
/usr/bin/avr-gdb
$ dpkg --listfiles gdb-avr
....
/usr/bin/avr-gdb
... weird...
anyway, I consider to build avr-gdb myself.
With python.
Best place to start?
> Your AVR Studio is quite old if you upgrade to a studio 6. Studio 7
> provides a new debug protocol, which is implemented in avarice but not
> very functional.
So it was no mistake being afraid of regression bugs?
I tried the most recent Studio 7, called for a windows upgrade, windows
upgrade stalled.
Is it really necessary / helpful / improvement from 4.19 to 6?
I hate to risk screwing a computer just for the opaqe extraction of
some binary firmware I cannot even get a version number of.
(well, I hate Win anyway, you may just realize...)
Habedieehre :-)
Wolfgang
>
> Cheers,
> Knut
>
> Am 18.03.2017 um 20:30 schrieb Wolfgang Rosner:
> > 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
|
