avarice und atmega32u2

[sep (Gast)]

Hallo,

Ich habe gerade ein kleines Problem und hoffe, dass mir hier jmd helfen 
kann. Also ich habe hier gerade eine sehr kompakte Schaltung mit einem 
ATmega32u2 drauf.
Ich hab zwar schon häufiger was mit den AVRs zu tun gehabt, aber eine 
längere Zeit schon nicht mehr auf diesen programmiert. Also bin ich 
gerade dabei die Toolchain ordentlich aufzubauen. Dazu gehört auch 
avarice.
Nachdem ich dann nun ein minimales Codebsp implementiert hatte, wollte 
ich probieren ob das debuggen geht.

#include <inttypes.h>
#include <avr/io.h>

FUSES =
{
    .low = FUSE_CKSEL0 & FUSE_SUT1,
    .high = FUSE_BOOTSZ0 & FUSE_BOOTSZ1 & FUSE_EESAVE & FUSE_SPIEN,
    .extended = FUSE_BODLEVEL0 & FUSE_HWBE,
};

int __attribute__((OS_main)) main( void ) {

    DDRB = ( 1 << PB7 );
    PORTB = 0;
    PORTB = ( 1 << PB7 );

    while(1);

    return 0;
}

Dieser kleine Codeschnipsel wird dann mit folgendem übersetzt.

$ avr-gcc -O0 -g -std=c99  -DF_CPU=8000000UL -c -mmcu=atmega32u2 -MMD -MP -MF"main.d" -MT"main.d" -c -o "main.o" "main.c"

Anschließend gelinkt und es entsteht die Elf-Datei.

Als ich dann avarice ausprobieren wollte ist mir aufgefallen, dass der 
atmega32u2 gar nicht unterstützt wird. Also hatte ich mich gestern Abend 
einmal auf die Suche gemacht und geschaut. Nachdem ich nichts dazu 
gefunden habe, habe ich mich selbst ran gesetzt, den atmega32u2 zu 
implemetieren (für avarice).
In ./src/ioreg.cc habe ich die entsprechenden Register hinzugefügt. Für 
die ./src/devdesc.cc habe ich ein wenig länger gesessen. Ich wurde dort 
bei der Installation von dem Atmel Studio fündig. Dort habe ich die 
device descriptions einfach übernommen.
Angehangen habe ich einen Patch. Kompilieren tut es und erkennen tut 
avarice den chip nun auch.
Nun konnte ich dann avarice laufen lassen eine log davon habe ich nun 
auch einmal angehangen.
So weit so gut. Avarice startet und wartet auf eine Verbindung.
Dann habe ich avr-gdb gestartet und da fängt es dann an komisch zu 
werden (auch angehangen).

Nachdem ich mittels

(gdb) target remote localhost:4242

 auf das Gerät gehe, ist der schon schön am laufen und ist an einer 
zufälligen Adresse. Da hilft kein Breakpoint, oder ein continue, der ist 
irgendwie komisch unterwegs. Mich beschleicht die Annahme, dass der 
Programmcode nicht ordentlich auf das Gerät übertragen wird.
Ob das nun an meinen "Abschreibkünsten" oder an meinen beschränkten 
Fähigkeiten mit gdb liegt kann ich keider nicht sagen.
Aus dem Grund würde ich euch gerne mal bitten einmal rüber zu schauen, 
wo mein Fehler liegt. Ich wäre euch sehr verbunden.

Aso. Mit dem AVR-Studio habe ich das schon einmal probiert. Da läuft das 
debuggen gut. Ist aber keine wirkliche Option für mich, da mein primäres 
System wohl doch eher linux ist.

Ggf kann ja auch einmal jmd das ausprobieren, wer ein atmega32u2 zu 
liegen hat. Zumindest weiß ich zZt nicht weiter und wäre für jeden 
Ratschlag dankbar.

Vielen Dank und viele Grüße
sep

[sep (Gast)]

Hey,

also ich habe noch einmal einiges geprüft. Die Sachen in der devdesc.cc 
sollten so weit stimmen. Ich komme ja auch auf den uC rauf.
Dann habe ich noch einmal diesen 
Beitrag "Porbleme mit JTAGICE mkii" gefunden.
Aus dem Grund habe ich bei meinem MKII einmal die Firmware geprüft und 
diese dann auf die 7.19er Version gedowngraded. Jedoch hat sich das 
Verhalten immer noch nicht geändert.
Also. Noch einmal zu meinem Vorgehen.
Ich baue das Projekt ganz normal.
Dann aktiviere ich DebugWire mit:

$ avrdude -c jtag2isp -p m32u2 -B4 -U lfuse:w:0xDE:m -U hfuse:w:0x51:m -U efuse:w:0xF6:m

Danach spiele ich die FW auf:

$ avrdude -c jtag2isp -p m32u2 -B4 -V -U flash:w:firmware.hex:i

Anschließend resette ich den uC. Dann starte ich avarice:

$ avarice -2 -P atmega32u2 -w -j usb -C :4242 -d

Am Ende dann starte ich gdb und verbinde mich dann damit zu avarice.

$ avr-gdb firmware.elf

(gdb) target remote :4242

Dort springt der Controller dann schon irgendwo im Code rum. Also 
zumindest wird der anscheinend nicht resettet.
Was ich nun noch fest gestellt habe. Wenn ich eine break-Anweisung in 
den Code eingefügt habe mit

__asm__ volatile( "break" );

dann bleibt der Controller natürlich auch dort stehen und wartet. Jedoch 
wenn ich steppe, dann blinkt mein MKII die ganze Zeit aber es tut sich 
einfach nix. Wenn ich ein continue mache, dann kommt er sofort wieder zu 
dieser break-Anweisung.
Kann das sein, dass der Controller nicht ordentlich resettet wird?

Viele Grüße
sep

[sep (Gast)]

Hey,

Also ich habe nun erst einmal eine erste Möglichkeit stepweise zu 
debuggen.
Problem ist jedoch immer noch, dass ich zu Anfang keine ordentliche 
Möglichkeit habe breakpoints zu setzen. Also der uC läuft gleich durch. 
Wie ich das nun mache. Gesetzt ich habe diesen Code:

#include <inttypes.h>
#include <avr/io.h>

FUSES =
{
    .low = FUSE_CKSEL0 & FUSE_SUT1,
    .high = FUSE_BOOTSZ0 & FUSE_BOOTSZ1 & FUSE_EESAVE & FUSE_SPIEN,
    .extended = FUSE_BODLEVEL0 & FUSE_HWBE,
};

int __attribute__((OS_main)) main( void ) {

    __asm__ volatile( "break" );

    DDRB = ( 1 << PB7 );
    PORTB = 0;
    PORTB = ( 1 << PB7 );

    while(1);

    return 0;
}

Den spiele ich auf, wie oben beschrieben und starte Avarice sowie 
avr-gdb und ich kann mich zu dem target verbinden.
Danach setze ich bsp einen Breakpoint und mache dann folgendes:

(gdb) b 16
(gdb) jump 15

Also ich setze den breakpoint in der Zeile

    PORTB = 0;

und springe hinter die break-Anweisung. Dann kann ich auch stepweise 
weiter machen oder andere breakpoints setzen, welche dann auch mit 
continue angesprungen werden.

Testweise habe ich dann auch heute noch die Versionen von avarice und 
avrdude aus dem Repository installiert. Jedoch brachte das auch keine 
Besserung. Dann hatte ich die Firmware des Atmel JTAG ICE mkII auch noch 
mal auf die 7.14 gedowngraded. Brachte leider auch nix.
Aso. Der patch den ich angehangen habe ist für die SVN Version von 
avarice für den 32U2. Da waren noch kleinere Änderungen nötig.
Wenn jmd eine Idee hat, wie ich da noch ein bissen Komfort rein bringen 
kann, dem wäre ich sehr dankbar. Denn das break und das jump müssten ja 
eigentlich nicht sein.
Aso. Wenn ich an einer break Anweisung mit dem Debugger hänge, ist auch 
das Problem, dass ein step sich aufhängt und ein continue wieder bei dem 
break landet. Aus dem Grund musste das jump her halten.

Viele Grüße
sep

[Jörg W. (dl8dtl) (Moderator)]

Bitte auf jeden Fall den Patch bei sourceforge im Projekt einreichen,
hier geht er verloren.

[sep (Gast)]

Hey,

habe ich nun einmal gemacht. Trotzdem existiert ja noch das eine 
Problem. Hast du dort vlt eine Ahnung, warum das so ist, oder ist dort 
alles iO und ich sehe das nicht?

Viele Grüße
sep

[Jörg W. (dl8dtl) (Moderator)]

sep schrieb:

> habe ich nun einmal gemacht.

Hab' ich gesehen, danke!

> Trotzdem existiert ja noch das eine
> Problem. Hast du dort vlt eine Ahnung, warum das so ist, oder ist dort
> alles iO und ich sehe das nicht?

Auf welche Weise lädst du den Code denn in den Controller, zuvor mit
AVRDUDE, oder über das "load"-Kommando des GDB?

Das hier ist auf jeden Fall nicht OK:

command[0x23, 1]: 23 
recv: timeout

command[0x23, 2]: 23 
recv: timeout

command[0x23, 3]: 23 
recv: timeout

command[0x23, 4]: 23 
recv: timeout

Andererseits ist das das "restore target"-Kommando, also bereits
beim Aufräumen.

Habe mir das Log gerade angesehen, nein, eine richtige Idee, warum
das schief läuft, habe ich auch nicht.  Anbei ein Log von einem
kurzen Test: breakpoint auf main(), continue, Breakpoint erreicht,
ein "step"-Kommando (was im AVaRICE natürlich mehrere Steps sind).

Sind auch einige Timeouts drin, aber insgesamt funktioniert es
zumindest.

[sep (Gast)]

Hey danke das du dort mal rüber schaust.
Ich werde heute Abend einmal die Log-Dateien vergleichen oder besser 
gesagt einmal rüber schauen. ZZt muss ich mich gerade um einige andere 
Sachen kümmern.

Jörg W. schrieb:
> Auf welche Weise lädst du den Code denn in den Controller, zuvor mit
> AVRDUDE, oder über das "load"-Kommando des GDB?

Ich lade das ganze mit AVRDude auf den Controller. Im ISP Mode. Danach 
trenne ich den uC einmal vom Strom und verbinde den Controller wieder 
mit meinem USB-Hub.
Danach starte ich avarice.

Alg. hab ich irgendwie mit meinem JTAG ICE mkII eine kleine Sache die 
mir nicht ganz so normal erscheint. Egal ob bei avrdude oder avarice.
Wenn ich per avrdude die Firmware lade, wird das Kommando erst ganz 
normal ausgeführt. Nachdem avrdude fertig geflasht hat, blinkt einmal 
die Connection-LED bei mir am USB-Hub.
Ich habe gerade einmal den DFU-Bootloader neu rauf geflasht. Es ist im 
dmesg zu sehen, dass zuerst das USB-Gerät neu erkannt wird, danach dann 
noch einmal der JTAG ICE mkII. Also, anscheinend wird der disconnected.

[ 2700.252102] usb 1-5.4: reset full-speed USB device number 15 using ehci-pci
[ 2700.288843] usb 1-5.4: USB disconnect, device number 15
[ 2700.668104] usb 1-5.3: new full-speed USB device number 16 using ehci-pci
[ 2700.763094] usb 1-5.3: New USB device found, idVendor=03eb, idProduct=2ff0
[ 2700.763100] usb 1-5.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2700.763104] usb 1-5.3: Product: ATmega32U2 DFU
[ 2700.763107] usb 1-5.3: Manufacturer: ATMEL
[ 2701.688096] usb 1-5.4: new full-speed USB device number 17 using ehci-pci
[ 2701.781847] usb 1-5.4: New USB device found, idVendor=03eb, idProduct=2103
[ 2701.781853] usb 1-5.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2701.781857] usb 1-5.4: Product: JTAGICE mkII
[ 2701.781861] usb 1-5.4: Manufacturer: ATMEL
[ 2701.781864] usb 1-5.4: SerialNumber: 070000004696

Ich habe nun eben noch einmal kurz zwei, drei steps via avr-gdb gemacht 
und dann einfach mit Strg+D die Session beendet. Es passiert auch, dass 
die USB-Verbindung kurz disconnected wird und danach der JATG ICE wieder 
erkannt wird.

[ 2997.171407] usb 1-5.4: USB disconnect, device number 20
[ 2998.392161] usb 1-5.4: new full-speed USB device number 21 using ehci-pci
[ 2998.485778] usb 1-5.4: New USB device found, idVendor=03eb, idProduct=2103
[ 2998.485784] usb 1-5.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2998.485788] usb 1-5.4: Product: JTAGICE mkII
[ 2998.485792] usb 1-5.4: Manufacturer: ATMEL
[ 2998.485795] usb 1-5.4: SerialNumber: 070000004696

Danke dir und viele Grüße
sep

[Jörg W. (dl8dtl) (Moderator)]

sep schrieb:
> Also, anscheinend wird der disconnected.

Ja, das ist beim JTAGICEmkII so.  Das hängt wohl damit zusammen, dass
sie zwei verschiedene Transportschichten benutzen können, JTAG und
RS-232.  Die erste, über die eine Kontaktaufnahme erfolgt, schaltet
den jeweils anderen Transport ab.  Am Ende erfolgt dann offenbar ein
kompletter Reset der Transportschichten.

Ach ja, beim mkII kannst du es natürlich auch mal via RS-232 probieren.
Das ist zwar bisschen langsamer, aber ich habe es geringfügig robuster
in Erinnerung.

Was mir gerade noch einfällt: ATmega32U2 ist debugWIRE.  Das verhält
sich in der Tat etwas anders als JTAG (was ich oben benutzt habe).

Beim Debuggen mit dem Atmel-ICE (geht nur mit aktuellem SVN-Stand)
über debugWIRE war mir auch aufgefallen, dass der erste Breakpoint
zuweilen nicht von selbst „auslöst“.  Da scheint sich noch irgendwo
eine Wanze versteckt zu haben.  In Wirklichkeit war der Breakpoint
dann auch erreicht worden; wenn man manuell unterbricht, steht er
genau da, wo der Breakpoint ist.

[sep (Gast)]

Jörg W. schrieb:
> oder über das "load"-Kommando des GDB?

Ganz vergessen. Wenn ich mit load aus dem gdb versuche das Programm zu 
laden bekomme ich bei avr-gdb folgendes:

(gdb) load                                                                                                                        
warning: Can not parse XML memory map; XML support was disabled at compile time                                                   
Loading section .text, size 0xc6 lma 0x0                                                                                          
Remote connection closed

Die avarice.log ist angehangen.
Zwecks dem XML-Fehler habe ich gerade einmal beim avr-gdb beim configure 
geschaut und ebenfalls bei avarice. Jedoch kann ich zumindest beim 
configure nichts von enable-xml, with-xml oder so was in der Art finden.

Gerade noch vor dem Absenden deine nachricht gelesen.
Ich nutze den Atmel JTAG ICE mkII.
Den Atmel ICE habe ich auch hier. Den kann ich zur not auch noch einmal 
ausprobieren.

Über RS232 probiere ich das heute Abend einmal. Hm. Da muss ich erst 
einmal Kabel suchen! :D

Viele Grüße
sep

[Jörg W. (dl8dtl) (Moderator)]

sep schrieb:
> warning: Can not parse XML memory map; XML support was disabled at
> compile time

Kommt mir bekannt vor.

Da habe ich mir auch schon mal den Wolf danach gesucht … Aber zum
Glück habe ich das nun im Makefile des FreeBSD-Ports drin stehen. ;-)

Der braucht eine expat-Bibliothek, mitsamt Headerfiles natürlich,
also unter Linux noch das entsprechende -dev Paket mit installieren.

Wenn man ihn damit compiliert, sollte er die XML memory map parsen
können.  Das "load"-Kommando verhält sich dann anders.

[sep (Gast)]

Hm, nun doch noch einmal alles schnell gemacht! :D
Bei gentoo gibt es ein useflag expat. Hm. Das hätte man wissen sollen.
Gerade noch einmal ein load ausprobiert. Die Ausgabe ist nun anders und 
avarice läuft noch.
Ich glaube ich muss die devdesc noch einmal prüfen.

$ avr-gdb
GNU gdb (Gentoo 7.11 vanilla) 7.11
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=avr".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) file firmware.elf 
Reading symbols from firmware.elf...done.
(gdb) target remote :4242
Remote debugging using :4242
0x00007e0a in ?? ()
(gdb) load
Loading section .fuse, size 0x3 lma 0x820000
Load failed
(gdb)

[Jörg W. (dl8dtl) (Moderator)]

sep schrieb:
> (gdb) load
> Loading section .fuse, size 0x3 lma 0x820000
> Load failed

Ich gebe zu, Fuses zu laden habe ich nie probiert.

Das kann bei debugWIRE nicht gehen, denn über dieses Interface kann
man die Fuses nicht verändern.

Bitte schreib' noch zusätzlich einen Bugreport. ;-)

In der Zwischenzeit kannst du ja einfach mal die Fuses aus deinem
Code rausnehmen.

[sep (Gast)]

Ha, nicht falsch verstehen... Ich könnt dich küssen.
Gerade als ich auf absenden geklickt habe, hab ich auch daran gedacht 
die fuses zu entfernen. So. Gesagt, getan und per load geladen und es 
läuft.
Danke dir!

$ avr-gdb
GNU gdb (Gentoo 7.11 vanilla) 7.11
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=avr".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) file firmware.elf 
Reading symbols from firmware.elf...done.
(gdb) target remote :4242
Remote debugging using :4242
0x00007bae in ?? ()
(gdb) load
Loading section .text, size 0xc4 lma 0x0
Start address 0x0, load size 196
Transfer rate: 563 bytes/sec, 49 bytes/write.
(gdb) b main
Breakpoint 1 at 0x92: file main.c, line 17.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.

Breakpoint 1, main () at main.c:17
17          DDRB = ( 1 << PB7 );
(gdb)

So. Um den Bug Report zwecks der fuses kümmere ich mich aber nun 
wirklich heute abend! ;)

Vielen, vielen Dank
sep