mikrocontroller.net

Forum: Compiler & IDEs ATtiny24 - ISR wird nie gerufen __vectors> fehlt


Autor: rolf-harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, habe den Eindruck, die ISR wird niemals aufgerufen:
-----------------------
ISR (USI_OVF_vect)
{
  PORTA |= _BV(PA0); //Test-Ausgang setzen
  usi_complete = 1;
  // Copy USIDR to buffer to prevent overwrite on next transfer.
  usi_DR = USIDR;
}
-----------------------

Hab mir daraufhin die .lst Datei angeschaut, "normalerweise" gibts dort 
immer  so eine Tabelle mit:
00000000 <__vectors>:

   0:  10 c0         rjmp  .+32       ; 0x22 <__ctors_end>

   2:  28 c0         rjmp  .+80       ; 0x54 <__bad_interrupt>

...usw.

In diesem Programm fehlt diese Tabelle, statt dessen gehts gleich mit:
00000000 <__ctors_end>:
   0:  10 e0         ldi  r17, 0x00  ; 0
   2:  a0 e6         ldi  r26, 0x60  ; 96
los.

Ich bin vollkommen ratlos. Hat schon mal jemand so was gesehen ?
Habe avr-gcc 4.1.1 & avr-libc 1.4.

Grüsse rolf-harry

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, dann hast du beim Linken irgendwas vermasselt.  Ich habe dein
Stückchen um die fehlenden Definitionen der beiden Variablen sowie
um ein leeres main() ergänzt, mit
avr-gcc -Os -mmcu=attiny24 -o foo.elf foo.c
compiliert und bekomme:
% avr-objdump -d foo.elf

foo.elf:     file format elf32-avr

Disassembly of section .text:

00000000 <__vectors>:
   0:   10 c0           rjmp    .+32            ; 0x22 <__ctors_end>
   2:   28 c0           rjmp    .+80            ; 0x54 <__bad_interrupt>
   4:   27 c0           rjmp    .+78            ; 0x54 <__bad_interrupt>
   6:   26 c0           rjmp    .+76            ; 0x54 <__bad_interrupt>
   8:   25 c0           rjmp    .+74            ; 0x54 <__bad_interrupt>
   a:   24 c0           rjmp    .+72            ; 0x54 <__bad_interrupt>
   c:   23 c0           rjmp    .+70            ; 0x54 <__bad_interrupt>
...
  1e:   1a c0           rjmp    .+52            ; 0x54 <__bad_interrupt>
  20:   1a c0           rjmp    .+52            ; 0x56 <__vector_16>

00000022 <__ctors_end>:
  22:   11 24           eor     r1, r1
  24:   1f be           out     0x3f, r1        ; 63
  26:   cf ed           ldi     r28, 0xDF       ; 223
...

Autor: rolf-harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antwort. So langsam glaube ich, das mit meinem gcc (oder 
linker) was nicht passt. Wenn ich das Gleiche mache, fehlt immer noch 
__vectors:

----------------- c-code:
#include <inttypes.h>
#include <avr/io.h>
#include <avr/interrupt.h>


volatile char usi_complete;
volatile char usi_DR;

ISR (USI_OVF_vect)
{
  PORTA |= _BV(PA0); //Test-Ausgang setzen
  usi_complete = 1;
  // Copy USIDR to buffer to prevent overwrite on next transfer.
  usi_DR = USIDR;
}

int main (void)

{

  DDRA |= _BV(DDA5);                      // DO
  PORTA |= _BV(PA4) | _BV(PA6);  // Pull-ups für DI/CLKL
  PORTA |=   _BV(PA2)| _BV(PA3)| _BV(PA7);
  PORTB |= _BV(PB0) | _BV(PB2)| _BV(PB3);

  DDRA |= _BV(DDA0); //Test-Ausgang
  PORTA &= ~_BV(PA0);
  DDRA |= _BV(DDA1); //Test-Ausgang
  PORTA &= ~_BV(PA1);

  // Configure USI to 3-wire slave mode, with int
  USICR = _BV (USIWM0) | _BV(USICS1)|_BV (USIOIE);
  sei();

  for (;;){

    if(usi_complete ){
      PORTA |= _BV(PA1);
      switch(usi_DR){
        case(0x11):{
          USIDR=0xaa;
          break;
          }
        case(0x22):{
          USIDR=0xbb;
          break;
          }
        case(0x33):{
          USIDR=0xcc;
          break;
          }
      }
      usi_complete=0;
      USISR = _BV(USIOIF);
      loop_until_bit_is_set(USISR, USIOIF);
    }
     }

  return (0);

}
----------------------------- ende c-code

avr-gcc -Os -mmcu=attiny24 -o foo1.elf ghl.c

avr-objdump -d   foo1.elf

foo1.elf:     file format elf32-avr

Disassembly of section .text:

00000000 <__ctors_end>:
   0:   10 e0           ldi     r17, 0x00       ; 0
   2:   a0 e6           ldi     r26, 0x60       ; 96
   4:   b0 e0           ldi     r27, 0x00       ; 0
   6:   e8 ea           ldi     r30, 0xA8       ; 168
   8:   f0 e0           ldi     r31, 0x00       ; 0
   a:   03 c0           rjmp    .+6             ; 0x12 
<.do_copy_data_start>

0000000c <.do_copy_data_loop>:
   c:   c8 95           lpm

Grüsse rolf-harry

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ruf mal den Compiler mit -v auf (und dem Rest der Kommandozeile 
natürlich).

Was für eine Installation/Version/... ist das denn?

Autor: rolf-harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, hier ist der Aufruf mit -v:
-------------------------------------------------
avr-gcc -v -Os -mmcu=attiny24 -o foo2.elf ghl.c
Using built-in specs.
Target: avr
Configured with: ../configure --prefix=/usr/local/avr --target=avr 
--enable-lang               uages=c --disable-nls --disable-libssp 
--with-dwarf2
Thread model: single
gcc version 4.1.1
 /usr/local/avr/libexec/gcc/avr/4.1.1/cc1 -quiet -v ghl.c -quiet 
-dumpbase ghl.c                -mmcu=attiny24 -auxbase ghl -Os -version 
-o /tmp/ccrTCpBl.s
ignoring nonexistent directory 
"/usr/local/avr/lib/gcc/avr/4.1.1/../../../../avr 
/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/avr/lib/gcc/avr/4.1.1/include
 /usr/local/avr/lib/gcc/avr/4.1.1/../../../../avr/include
End of search list.
GNU C version 4.1.1 (avr)
        compiled by GNU C version 3.4.4 20050314 (prerelease) (Debian 
3.4.3-13sa               rge1).
GGC heuristics: --param ggc-min-expand=99 --param 
ggc-min-heapsize=129534
Compiler executable checksum: a8184b2ff31c5a915e800b494000c2c7
 /usr/local/avr/lib/gcc/avr/4.1.1/../../../../avr/bin/as -mmcu=attiny24 
-o tmp               cc4zujlS.o /tmp/ccrTCpBl.s
 /usr/local/avr/lib/gcc/avr/4.1.1/../../../../avr/bin/ld -o foo2.elf 
-L/usr/loca               l/avr/lib/gcc/avr/4.1.1 
-L/usr/local/avr/lib/gcc/avr/4.1.1/../../../../avr/lib / 
tmp/cc4zujlS.o -lgcc -lc -lgcc
-------------------------------------------------

Habe Debian Sarge i386.
Die ganze avr-toolchain hab ich nach der (übrigens sehr guten) Anleitung 
auf nongnu.org/avr-libc gebaut, weil die aktuellen (stable) Pakete von 
Debain den tiny24 nicht kennen.

Habe also zuerst die binutils gebaut, dann gcc, dann avr-libc.

Beim gcc hab ich alle Patches (wpatch-0b-constants, patch-bug25672, 
patch-libiberty-Makefile.in, patch-zz-atmega256x, patch-attribute_alias, 
patch-dwarf, patch-newdevices) vor dem ./configure angewendet.

Für die binutils werden in der Anleitung ja auch Patches empfohlen, 
allerding muss ich gestehen, dass ich das gelassen habe, ich wusste 
nicht welche ich nehmen sollte.

Zusammengefasst siehts also so aus:
binutils 2.17
gcc 4.11 (mit Patches)
avr-libc 1.4.5

Grüsse rolf-harry

Autor: rolf-harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist noch dieses

ignoring nonexistent directory 
"/usr/local/avr/lib/gcc/avr/4.1.1/../../../../avr/sys-include"

in der Ausgabe aufgefallen.

Kann das ein Ansatz sein ?

Grüsse rolf-harry

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Kann das ein Ansatz sein?

Nein, das ist OK.  Aber irgendwas ist mit dem Compiler vergurkt, denn
er übergibt dem Linkeraufruf das crttn24.o nicht mit.  So sieht das
bei mir aus:
Using built-in specs.
Target: avr
Configured with: ./../gcc-4.1.1/configure --target=avr --disable-libssp --prefix=/usr/local i386-portbld-freebsd6.1
Thread model: single
gcc version 4.1.1
 /usr/local/libexec/gcc/avr/4.1.1/cc1 -quiet -v ghl.c -fno-delete-null-pointer-checks -quiet -dumpbase ghl.c -mmcu=attiny24 -auxbase ghl -Os -version -o /var/tmp//ccJmFa5r.s
ignoring nonexistent directory "/usr/local/lib/gcc/avr/4.1.1/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/avr/4.1.1/include
 /usr/local/lib/gcc/avr/4.1.1/../../../../avr/include
End of search list.
GNU C version 4.1.1 (avr)
        compiled by GNU C version 3.4.4 [FreeBSD] 20050518.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64436
Compiler executable checksum: e05a4be084b8452f07f20cde87edd4f1
 /usr/local/lib/gcc/avr/4.1.1/../../../../avr/bin/as -mmcu=attiny24 -o /var/tmp//ccTRstgR.o /var/tmp//ccJmFa5r.s
 /usr/local/lib/gcc/avr/4.1.1/../../../../avr/bin/ld -m avr2 -o foo2.elf /usr/local/lib/gcc/avr/4.1.1/../../../../avr/lib/crttn24.o -L/usr/local/lib/gcc/avr/4.1.1 -L/usr/local/lib/gcc/avr/4.1.1/../../../../avr/lib /var/tmp//ccTRstgR.o -lgcc -lc -lgcc

(Der Präfix ist bei mir /usr/local, nicht /usr/local/avr.  Aber das ist
eigentlich egal, solange alle Teile der Toolchain gleichermaßen damit
konfiguriert worden sind.)

Autor: rolf-harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, ich frage mich, ob ich wohl mit dem Patchen was falsch gemacht hab, 
aber der gcc hatte sich ohne Meckern gebaut.

Den Päfix hab immer benutzt.

Kann es auch an den binutils liegen (da hab ich nix gepatched), oder 
kann man anhand der Ausgaben das Problem auf den gcc eingrenzen ?

Grüsse rolf-harry

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke, dass es der GCC ist, der die Kommandozeile flashc zusammmen
baut.

Du kannst mal "avr-gcc -dumpspecs" aufrufen.  Da muss sich unter
*crt_binutils finden:

%{mmcu=attiny24:crttn24.o%s}

Autor: rolf-harry (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Aha, "avr-gcc -dumpspecs |grep attiny24" ergibt: nix!

Habe die Ausgabe als Datei angehängt.

Grüsse rolf-harry

Autor: rolf-harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich aber das hier mache (tiny26):

"avr-gcc -v -Os -mmcu=attiny26 -o foo3.elf ghl.c"
"avr-objdump -d foo3.elf"

Ist die __vectors Tabelle vorhanden.

Grüsse rolf-harry

Autor: rolf-harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich muss doch nochmal mit den binutils nerven: Wie gesagt, da hab ich ja 
nix gepatched, eben hab ich nochmal unter

http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/...

geguckt, dort gibt es unter Revision 1.3 "Add support for ATtiny24/44/84 
devices" etwas, das ich möglicherweise doch hätte nehmen sollen ?

Grüsse rolf-harry

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rolf-harry wrote:

> ..., dort gibt es unter Revision 1.3 "Add support for ATtiny24/44/84
> devices" etwas, das ich möglicherweise doch hätte nehmen sollen ?

Nein, wenn du dir den aktuellen "newdevices"-Patch ansiehst, fügt der
nur noch ein paar von den neuen Picopower-AVRs hinzu, der Rest ist
bei binutils 2.17 bereits von Haus aus dabei.

Das muss in deinem GCC liegen, irgendwie sieht mir das aus, als hättest
du den nicht vollständig gepatcht.  Dadurch wird zwar -mmcu=attiny24
prinzipiell erkannt, aber der Teil des Patches, der das crttn24.o zu
den (internen) Specs hinzufügt, scheint wohl zu fehlen:

@@ -799,6 +854,15 @@
 %{mmcu=at86rf401:crt86401.o%s} \
 %{mmcu=attiny13:crttn13.o%s} \
 %{mmcu=attiny2313:crttn2313.o%s} \
+%{mmcu=attiny24:crttn24.o%s} \
+%{mmcu=attiny44:crttn44.o%s} \
+%{mmcu=attiny84:crttn84.o%s} \
+%{mmcu=attiny25:crttn25.o%s} \
+%{mmcu=attiny45:crttn45.o%s} \
+%{mmcu=attiny85:crttn85.o%s} \
+%{mmcu=attiny261:crttn261.o%s} \
+%{mmcu=attiny461:crttn461.o%s} \
+%{mmcu=attiny861:crttn861.o%s} \
 %{mmcu=atmega103|mmcu=avr3:crtm103.o%s} \
 %{mmcu=atmega603:crtm603.o%s} \
 %{mmcu=at43usb320:crt43320.o%s} \

Hast du denn beim Patchen irgendwo ein .rej-File bekommen?

Ich würde ja vermuten, dass die anderen in obigem Stück genannten
CPUs unter dem gleichen Problem leiden.

Autor: rolf-harry (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nein, hab eben nochmal /usr/local nach *.rej abgesucht, da ist nix.

Der Teil oben ist jedenfalls in der avr.h gelandet.

Bin aber trotzdem nicht so sicher, alles richtig gemacht zu haben, habe 
die patches (wie weiter oben beschrieben) runtergeladen, und vor dem 
.configure so aufgerufen:

patch -p0 < /usr/local/patches/files/patch-newdevices
patch -p0 < /usr/local/patches/files/patch-0b-constants
patch -p0 < /usr/local/patches/files/patch-attribute_alias
patch -p0 < /usr/local/patches/files/patch-bug25672
patch -p0 < /usr/local/patches/files/patch-dwarf
patch -p0 < /usr/local/patches/files/patch-libiberty-Makefile.in
patch -p0 < /usr/local/patches/files/patch-newdevices

Und richtig, mit einem tiny44 z.B. habe ich das gleiche Problem...

Grüsse rolf-harry

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die reject-Dateien würden auch nicht in /usr/local liegen, sondern in
deinem GCC-Build-Verzeichnis (nach dem Patchen).

Du hast den newdevices-Patch in obiger Folge zweimal drin, also das
muss schief gehen. :-o  Ansonsten werden die Patches der FreeBSD-Ports
in alphabetischer Reihenfolge appliziert.

Autor: rolf-harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tausend Dank, Jörg, das wars. Ich hatte das wohl beim Patchen 
vermasselt.

Nach dem "Neubau" des gcc ist die __vectors Tabelle da!

Grüsse rolf-harry

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.