mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR-GCC/avr-libc bug? (ATMega644)


Autor: Daniel M. (usul27)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kämpfe nun seit knapp einem Tag mit einem Problem, was mir völlig 
unverständlich ist.
Ich erzeuge in einer ISR ein paar Signale und möchte im Hauptprogramm 
eigentlich nur eine 32-bit-Variable setzen (die als Volatile definiert 
ist).

Der Main-Loop sieht so aus:

int main() {
  initialize();
  uint32_t j=65536UL;
  uint8_t i=1;
  while (1) {
    _delay_ms(10000);
    j=65536UL*i;
    setStepSize(j);
    settings2Uart();
    uart_puti(i);
    uart_putnl();
    i++;
    uart_puti(i);
    uart_putnl();
  }
}

(das meiste ist debug-Code). Nun passiert zählt i bis auf 16 und dann 
passiert nichts mehr. Interessanterweise funktioniert es richtig, wenn 
ich _delay_ms auskommentiere.
Irgendwie vermute ich ein Problem entweder mit dem Compiler der mit 
avr-libc, allerdings sehe ich im lss-File nicht direkt, wo das Problem 
liegen könnte.

Gibt es ausser dem -mcpu-Flag noch irgendwelche Compileroptionen, die 
man
zwingend setzen muss (AVR GCC 4.2.3)?

int main() {
    18c4:  1f 93         push  r17
    18c6:  cf 93         push  r28
    18c8:  df 93         push  r29
  initialize();
    18ca:  0e 94 f9 0b   call  0x17f2  ; 0x17f2 <initialize>
    18ce:  11 e0         ldi  r17, 0x01  ; 1
    18d0:  c0 e7         ldi  r28, 0x70  ; 112
    18d2:  d1 e0         ldi  r29, 0x01  ; 1
    18d4:  2f ef         ldi  r18, 0xFF  ; 255
    18d6:  3f ef         ldi  r19, 0xFF  ; 255
    18d8:  ce 01         movw  r24, r28
    18da:  01 97         sbiw  r24, 0x01  ; 1
    18dc:  f1 f7         brne  .-4        ; 0x18da <main+0x16>
    {
      // wait 1/10 ms
      _delay_loop_2(((F_CPU) / 4e3) / 10);
      __ticks --;
    18de:  21 50         subi  r18, 0x01  ; 1
    18e0:  30 40         sbci  r19, 0x00  ; 0
    __ticks = 1;
  else if (__tmp > 65535)
  {
    //  __ticks = requested delay in 1/10 ms
    __ticks = (uint16_t) (__ms * 10.0);
    while(__ticks)
    18e2:  d1 f7         brne  .-12       ; 0x18d8 <main+0x14>
  uint32_t j=65536UL;
  uint8_t i=1;
  while (1) {
    _delay_ms(10000);
    j=65536UL*i;
    18e4:  81 2f         mov  r24, r17
    18e6:  90 e0         ldi  r25, 0x00  ; 0
    18e8:  a0 e0         ldi  r26, 0x00  ; 0
    18ea:  b0 e0         ldi  r27, 0x00  ; 0
    18ec:  dc 01         movw  r26, r24
    18ee:  99 27         eor  r25, r25
    18f0:  88 27         eor  r24, r24
    18f2:  80 93 00 01   sts  0x0100, r24
    18f6:  90 93 01 01   sts  0x0101, r25
    18fa:  a0 93 02 01   sts  0x0102, r26
    18fe:  b0 93 03 01   sts  0x0103, r27
    setStepSize(j);
    settings2Uart();
    1902:  0e 94 92 0b   call  0x1724  ; 0x1724 <settings2Uart>
    uart_puti(i);
    1906:  81 2f         mov  r24, r17
    1908:  90 e0         ldi  r25, 0x00  ; 0
    190a:  0e 94 ea 0c   call  0x19d4  ; 0x19d4 <uart_puti>
    uart_putnl();
    190e:  0e 94 97 0c   call  0x192e  ; 0x192e <uart_putnl>
    i++;
    1912:  1f 5f         subi  r17, 0xFF  ; 255
    uart_puti(i);
    1914:  81 2f         mov  r24, r17
    1916:  90 e0         ldi  r25, 0x00  ; 0
    1918:  0e 94 ea 0c   call  0x19d4  ; 0x19d4 <uart_puti>
    uart_putnl();
    191c:  0e 94 97 0c   call  0x192e  ; 0x192e <uart_putnl>
    1920:  d9 cf         rjmp  .-78       ; 0x18d4 <main+0x10>

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ist kaum was nachzuvollziehen.

Evtl. überschreibt eine deiner Routinen ein Variable im RAM. DU siehst 
ja selbst dass der Code korrekt übersetzt ist.

Wenn sich der Verdacht auf einen gcc-Bug verdichten, lies mal 
Compilerfehler durch, und bastle ein minimal-Beispiel. Ausserdem 
sind in 4.2.3 bestimmt bekannte Bugs drinne, die z.B. in 4.2.x mit x>3 
behoben sind.

Johann

Autor: Roland Riegel (roland) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

Ohne dass Du die ISR postest, kann man da wenig sagen. Wo ist was 
volatile deklariert? Ich seh da nichts.
Aus der main() könntest Du auch mal das Debug-Zeugs rauswerfen, das 
verwirrt nur. Was soll das ganze eigentlich erreichen?

Gruß,
Roland

Autor: Mike J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann sein dass settings2Uart(); dein UART Einstellungen zerschießt und 
du deshalb nichts mehr empfängst.

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.