AVR führt Programm nicht aus, wenn zusätzliche Funktionen definiert sind

[Hauke (Gast)]

Hallo,
ich bin Neuling was AVR-C und Mikrocontroller im Allgemeinen an geht und 
probiere gerade erste Sachen aus. Könnt ihr mir erklären, warum dieses 
Programm...

#define F_CPU 1000000UL

#include <avr/io.h>
#include <util/delay.h>

int main(void)
{
  DDRB |= (1 << PB4);

  while (1) {
    PORTB ^= (1 << PB4);
    _delay_ms(500);
  }

  return 0;
}

...ausgeführt wird (die LED blinkt), aber dieses:

#define F_CPU 1000000UL

#include <avr/io.h>
#include <util/delay.h>

int test(int i);

int main(void)
{
  DDRB |= (1 << PB4);

  while (1) {
    PORTB ^= (1 << PB4);
    _delay_ms(500);
  }

  return 0;
}

int test(int i)
{
  return 1;
}

...scheinbar nicht (LED bleibt aus)?

[Peter II (Gast)]

was ist es denn für ein AVR?

[Hauke (Gast)]

Ein ATtiny85... hätte ich vielleicht erwähnen sollen^^

[Stefan F. (Gast)]

Sind das wirklich genau die beiden Programme, die du ausprobiert hast?

Oder hast du sie hier nur hin geschrieben, um deine Frage zu 
verdeutlichen, aber in Wirklichkeit ist das Programm komplexer?

Ich frage, weil ich an deinem zitierten Code keine Ursache für den 
Fehler sehen kann.

[Hauke (Gast)]

Das ist exakt das, was ich mit avr-gcc übersetzt habe.

[Jim M. (turboj)]

Ich sehe auf den ersten Blick keinen Grund. Sind die Compiler Warnungen 
an?
Fehler beim Flashen?

[Hauke (Gast)]

Habe keine Fehler beim Flashen mit AVRISP mkII, sind die 
Compilerwarnungen standardmäßig an? Ich führe folgendes aus:

avr-gcc --mmcu=attiny85 -Os -c test.c -o test.o
avr-gcc test.o -o test.elf
avr-objcopy -O ihex -j .text -j.data test.elf test.hex
avrdude -p t85 -c avrispmkii -U flash:w:test.hex:a

Vielleicht liegt der Fehler auch darin. Danke schonmal für die schnellen 
Antworten bis jetzt!

[Walter S. (avatar)]

am Programm liegt es nicht,
poste doch Mal alle Ausgaben die beim Compilieren, linken und flashen 
kommen

[Hauke (Gast)]

Habe jetzt mal extra -v (verbose) angehängt:

http://hastebin.com/equveyitif.py

[Stefan F. (Gast)]

Ich sehe da keinen Fehler. Hast du an dem Mikrocontroller einen 
Abblockkondensator? Und ist die Spannungsversorgung stabil genug?

[Hauke (Gast)]

Ja, habe ich. Die Versorgungsspannung kommt aus einem L78S05, der ist 
auch mit Kondensatoren bestückt.

Mal davon abgesehen: Was spricht dafür, dass es an der Schaltung liegt? 
Die LED blinkt doch einwandfrei, wenn ich das erste Programm flashe.

Liegt es eventuell an meiner Toolchain? Ist es einen Versuch wert, diese 
selber nochmal zu kompilieren?

[ProjektX (Gast)]

Am, zumindest uns gezeigten, Teil des Programms liegt es nicht. Deine 
int test(int i) - Funktion wird nicht in der main ausgeführt, somit wird 
diese wegoptimiert und übrig bleibt nur Teil, der auch dem ersten 
Programm entspricht.

Hast du zwischendurch die Optimierung ausgeschaltet o.ä.? Weil dann 
nämlich delay.h nicht mehr funktionieren würde.

Ansonsten fehlen weitere Informationen.

[Hauke (Gast)]

Das Programm ist nur ein Test, dementsprechend wirklich vollständig 
oben abgebildet. Die Optimierung habe ich zumindest nicht bewusst 
ausgeschaltet, ich habe den Schalter -Os von avr-gcc verwendet.

Dass die Funktion test() nicht ausgeführt wird, ist Absicht. Du sprichst 
von "Wegoptimierung", das heißt der Compiler erkennt, dass die Funktion 
keine Referenz hat. Würde meine Toolchain richtig funktionieren, müsste 
der µC also exakt das gleiche Programm vorgesetzt bekommen.

Es liegt also mit hoher Wahrscheinlichkeit an GCC & Co, sehe ich das 
richtig?

[Stefan F. (Gast)]

Erzeuge mal ein Assembler-Listing von beiden Varianten. Dann kannst du 
sie miteinander vergleichen und kontrolliere, um zu beurteilen, ob der 
Compiler fehlerhaft arbeitet.

objdump -h -S < test.elf

[Kugl (Gast)]

Hauke schrieb:

> Es liegt also mit hoher Wahrscheinlichkeit an GCC & Co, sehe ich das
> richtig?

Nein.

Post doch bitte die zugehörigen lss-Dateien.

[Stefan F. (Gast)]

Sorry, es muss "avr-objdump -h -S test.elf" heissen.

[Stefan F. (Gast)]

Mein Compiler erzeugt diesen Code für das erste Programm:

00000000 <main>:
   0:   bc 9a           sbi     0x17, 4 ; 23
   2:   90 e1           ldi     r25, 0x10       ; 16
   4:   88 b3           in      r24, 0x18       ; 24
   6:   89 27           eor     r24, r25
   8:   88 bb           out     0x18, r24       ; 24
   a:   2f e9           ldi     r18, 0x9F       ; 159
   c:   36 e8           ldi     r19, 0x86       ; 134
   e:   81 e0           ldi     r24, 0x01       ; 1
  10:   21 50           subi    r18, 0x01       ; 1
  12:   30 40           sbci    r19, 0x00       ; 0
  14:   80 40           sbci    r24, 0x00       ; 0
  16:   e1 f7           brne    .-8             ; 0x10 <__zero_reg__+0xf>
  18:   00 c0           rjmp    .+0             ; 0x1a <__zero_reg__+0x19>
  1a:   00 00           nop
  1c:   f3 cf           rjmp    .-26            ; 0x4 <__zero_reg__+0x3>

Und dieses für das zweite Programm:

00000000 <test>:
   0:   81 e0           ldi     r24, 0x01       ; 1
   2:   90 e0           ldi     r25, 0x00       ; 0
   4:   08 95           ret

00000006 <main>:
   6:   bc 9a           sbi     0x17, 4 ; 23
   8:   90 e1           ldi     r25, 0x10       ; 16
   a:   88 b3           in      r24, 0x18       ; 24
   c:   89 27           eor     r24, r25
   e:   88 bb           out     0x18, r24       ; 24
  10:   2f e9           ldi     r18, 0x9F       ; 159
  12:   36 e8           ldi     r19, 0x86       ; 134
  14:   81 e0           ldi     r24, 0x01       ; 1
  16:   21 50           subi    r18, 0x01       ; 1
  18:   30 40           sbci    r19, 0x00       ; 0
  1a:   80 40           sbci    r24, 0x00       ; 0
  1c:   e1 f7           brne    .-8             ; 0x16 <main+0x10>
  1e:   00 c0           rjmp    .+0             ; 0x20 <main+0x1a>
  20:   00 00           nop
  22:   f3 cf           rjmp    .-26            ; 0xa <main+0x4>

Beim Reset beginnt die Programmausführung an Adresse 0. Hier steht die 
Test-Funktion, die nach den beiden ldi Befehlen mit ret zurück kehrt. 
Und an dieser Stelle stürzt der µC ab,wiel die Funktion nicht mit call 
aufgerufen wurde.

Eigentlich hätte sie hinter <main> stehen müssen. Außerdem fehlt in 
beiden Fällen eine ganze Menge Code, nämlich die 
Initialisierungsroutinen der libc.

Wenn ich das längere Programm mit meinem erprobten Makefile compiliere, 
kommt was ganz anderes raus:

00000000 <__vectors>:
   0:  0e c0         rjmp  .+28       ; 0x1e <__ctors_end>
   2:  15 c0         rjmp  .+42       ; 0x2e <__bad_interrupt>
   4:  14 c0         rjmp  .+40       ; 0x2e <__bad_interrupt>
   6:  13 c0         rjmp  .+38       ; 0x2e <__bad_interrupt>
   8:  12 c0         rjmp  .+36       ; 0x2e <__bad_interrupt>
   a:  11 c0         rjmp  .+34       ; 0x2e <__bad_interrupt>
   c:  10 c0         rjmp  .+32       ; 0x2e <__bad_interrupt>
   e:  0f c0         rjmp  .+30       ; 0x2e <__bad_interrupt>
  10:  0e c0         rjmp  .+28       ; 0x2e <__bad_interrupt>
  12:  0d c0         rjmp  .+26       ; 0x2e <__bad_interrupt>
  14:  0c c0         rjmp  .+24       ; 0x2e <__bad_interrupt>
  16:  0b c0         rjmp  .+22       ; 0x2e <__bad_interrupt>
  18:  0a c0         rjmp  .+20       ; 0x2e <__bad_interrupt>
  1a:  09 c0         rjmp  .+18       ; 0x2e <__bad_interrupt>
  1c:  08 c0         rjmp  .+16       ; 0x2e <__bad_interrupt>

0000001e <__ctors_end>:
  1e:  11 24         eor  r1, r1
  20:  1f be         out  0x3f, r1  ; 63
  22:  cf e5         ldi  r28, 0x5F  ; 95
  24:  d2 e0         ldi  r29, 0x02  ; 2
  26:  de bf         out  0x3e, r29  ; 62
  28:  cd bf         out  0x3d, r28  ; 61
  2a:  02 d0         rcall  .+4        ; 0x30 <main>
  2c:  10 c0         rjmp  .+32       ; 0x4e <_exit>

0000002e <__bad_interrupt>:
  2e:  e8 cf         rjmp  .-48       ; 0x0 <__vectors>

00000030 <main>:
  30:  bc 9a         sbi  0x17, 4  ; 23
  32:  90 e1         ldi  r25, 0x10  ; 16
  34:  88 b3         in  r24, 0x18  ; 24
  36:  89 27         eor  r24, r25
  38:  88 bb         out  0x18, r24  ; 24
  3a:  2f e9         ldi  r18, 0x9F  ; 159
  3c:  36 e8         ldi  r19, 0x86  ; 134
  3e:  81 e0         ldi  r24, 0x01  ; 1
  40:  21 50         subi  r18, 0x01  ; 1
  42:  30 40         sbci  r19, 0x00  ; 0
  44:  80 40         sbci  r24, 0x00  ; 0
  46:  e1 f7         brne  .-8        ; 0x40 <__SREG__+0x1>
  48:  00 c0         rjmp  .+0        ; 0x4a <__SREG__+0xb>
  4a:  00 00         nop
  4c:  f3 cf         rjmp  .-26       ; 0x34 <main+0x4>

0000004e <_exit>:
  4e:  f8 94         cli

00000050 <__stop_program>:
  50:  ff cf         rjmp  .-2        ; 0x50 <__stop_program>

So sieht es aber richtig aus. Am Anfang ab Adresse 0 kommen die ganzen 
Interrupt-Vektoren, dann die Initialisierung (<__ctors_end>) und die 
springt zu <main>.

Mein Makefile führt folgenden Kommandos aus:

avr-gcc -c -Wall -O1 -fshort-enums -mmcu=attiny85 -DF_CPU=1000000 
-ffunction-sections -fdata-sections -std=c99   -o test2.o test2.c
avr-gcc -Wall -O1 -fshort-enums -mmcu=attiny85 -DF_CPU=1000000 
-ffunction-sections -fdata-sections -lm -Wl,--gc-sections -o test.elf 
test2.o
avr-objcopy -j .text -j .data -O ihex test.elf test.hex

[Stefan F. (Gast)]

Die Fehlerursache ist, dass du beim zweiten gcc Aufruf den Parameter 
"-mmcu=attiny85" vergessen hast.

[Hauke (Gast)]

DANKE VIELMALS!

Meine Güte, da hätte ich noch lange nach gesucht...

Also war ich mit meiner Vermutung ganz in der Nähe des Problems (hatte 
für mich selber nicht ausgeschlossen, dass ich avr-gcc falsch verwende). 
Ich merke schon, das Beste ist, ich befasse mich jetzt mit Assembler und 
wenn ich darin flüssig bin, steige ich wieder auf C um.

Danke an alle für die schnellen Antworten. Problem gelöst, PEBKAC!

[Stefan F. (Gast)]

Ein bisschen Assembler Grundkenntnisse helfen in der Tat bei der 
Fehlersuche.

Hier kannst es spielerisch lernen: 
http://stefanfrings.de/avr_workshop/index.html

[Peter D. (peda)]

Hauke schrieb:
> Ich merke schon, das Beste ist, ich befasse mich jetzt mit Assembler und
> wenn ich darin flüssig bin, steige ich wieder auf C um.

Es sollte schon reichen, wenn Du einfach die Meldungen des Compilers 
liest.

warning: #warning "device type not defined"

Profis nehmen den Schalter "-Werror", dann bricht der Compiler schon bei 
Warnungen ab.

[Possetitjel (Gast)]

Peter D. schrieb:

> Es sollte schon reichen, wenn Du einfach die Meldungen
> des Compilers liest.
>
> warning: #warning "device type not defined"

Und wo genau im oben geposteten Compiler-Output finde ich
diese Zeile? Vielen Dank im Voraus.

[Peter D. (peda)]

Ich hatte nur im Beitrag von Stefan Us gelesen, daß -mmcu fehlen soll.
Das gepostete Make ist ja von Stefan Us.
Dein Make hast Du nicht gezeigt.

Wenn ich -mmcu weglasse, kommt bei mir die Warnung im Consolenfenster.