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


von rolf-harry (Gast)


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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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
1
avr-gcc -Os -mmcu=attiny24 -o foo.elf foo.c
compiliert und bekomme:
1
% avr-objdump -d foo.elf
2
3
foo.elf:     file format elf32-avr
4
5
Disassembly of section .text:
6
7
00000000 <__vectors>:
8
   0:   10 c0           rjmp    .+32            ; 0x22 <__ctors_end>
9
   2:   28 c0           rjmp    .+80            ; 0x54 <__bad_interrupt>
10
   4:   27 c0           rjmp    .+78            ; 0x54 <__bad_interrupt>
11
   6:   26 c0           rjmp    .+76            ; 0x54 <__bad_interrupt>
12
   8:   25 c0           rjmp    .+74            ; 0x54 <__bad_interrupt>
13
   a:   24 c0           rjmp    .+72            ; 0x54 <__bad_interrupt>
14
   c:   23 c0           rjmp    .+70            ; 0x54 <__bad_interrupt>
15
...
16
  1e:   1a c0           rjmp    .+52            ; 0x54 <__bad_interrupt>
17
  20:   1a c0           rjmp    .+52            ; 0x56 <__vector_16>
18
19
00000022 <__ctors_end>:
20
  22:   11 24           eor     r1, r1
21
  24:   1f be           out     0x3f, r1        ; 63
22
  26:   cf ed           ldi     r28, 0xDF       ; 223
23
...

von rolf-harry (Gast)


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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

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

von rolf-harry (Gast)


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

von rolf-harry (Gast)


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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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:
1
Using built-in specs.
2
Target: avr
3
Configured with: ./../gcc-4.1.1/configure --target=avr --disable-libssp --prefix=/usr/local i386-portbld-freebsd6.1
4
Thread model: single
5
gcc version 4.1.1
6
 /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
7
ignoring nonexistent directory "/usr/local/lib/gcc/avr/4.1.1/../../../../avr/sys-include"
8
#include "..." search starts here:
9
#include <...> search starts here:
10
 /usr/local/lib/gcc/avr/4.1.1/include
11
 /usr/local/lib/gcc/avr/4.1.1/../../../../avr/include
12
End of search list.
13
GNU C version 4.1.1 (avr)
14
        compiled by GNU C version 3.4.4 [FreeBSD] 20050518.
15
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64436
16
Compiler executable checksum: e05a4be084b8452f07f20cde87edd4f1
17
 /usr/local/lib/gcc/avr/4.1.1/../../../../avr/bin/as -mmcu=attiny24 -o /var/tmp//ccTRstgR.o /var/tmp//ccJmFa5r.s
18
 /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.)

von rolf-harry (Gast)


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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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}

von rolf-harry (Gast)


Angehängte Dateien:

Lesenswert?

Aha, "avr-gcc -dumpspecs |grep attiny24" ergibt: nix!

Habe die Ausgabe als Datei angehängt.

Grüsse rolf-harry

von rolf-harry (Gast)


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

von rolf-harry (Gast)


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/avr-binutils/files/patch-newdevices

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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.

von rolf-harry (Gast)


Angehängte Dateien:

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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.

von rolf-harry (Gast)


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

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.