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 <[email protected]>: > 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 <[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 :-) > >> > >> > > > > > -- Wolfgang Rosner ------------------------------------------------------------------------------ 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
