AVR-GCC/avr-libc bug? (ATMega644)

[Daniel M. (usul27)]

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>

[Johann L. (gjlayde)]

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

[Roland R. (roland)]

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

[Mike J. (Gast)]

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