ATmega32 uint32_t Problem

[cemizm (Gast)]

Hallo Ihrs,

ich habe ein merkwürdiges Problem bei meinem kleinen Test Uhr Projekt.
Erstmal der Code dazu:

volatile unsigned long int seconds;

int main(void)
{
  seconds = 10; //Im Debugger wird immernoch 0 anezgeigt
  while(1)
  {
    if(seconds > 0) //trift nicht zu
      seconds--;
    
    seconds++; //keine Änderung.
  }
}

Das ist jetzt nicht mein Projekt aber ich habe im Zuge des debbugens ein 
neues Projekt zum lokalisieren des Problems erstellt.

Debugge ich den Code oben mit dem AVR-Simulator tut es genau was es 
soll. Seconds wird auf 10 gesetzt, in der Schleife trifft die Bedingung 
zu und es wird dekrementiert und im Anschluss wieder erhöht.

Wenn ich das ganze mit meinem Dragon auf dem STK500 debugge, ändert sich 
'seconds' nie.

Um ein Problem mit dem Dragon auszuschliessen habe ich auch ein Projekt 
erstellt bei dem eine LED aufleuchten sollte wenn 'seconds > 0'. Dies 
habe ich dann einfach per ISP übertragen, doch das Ergebnis ist das 
selbe.

Was mir aufgefallen ist wenn ich statt usinged long int einfach nur int 
nehme funktioniert das ganze wunderbar.

Wird hier irgendwas wegoptimiert oder hat der ATmega32 ein Problem mit 
dem uint32_t? Hier noch mal den Inhalt der .lss:

Test.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000000ee  00000000  00000000  00000074  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .bss          00000004  00800060  00800060  00000162  2**0
                  ALLOC
  2 .debug_aranges 00000020  00000000  00000000  00000162  2**0
                  CONTENTS, READONLY, DEBUGGING
  3 .debug_pubnames 00000027  00000000  00000000  00000182  2**0
                  CONTENTS, READONLY, DEBUGGING
  4 .debug_info   00000063  00000000  00000000  000001a9  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_abbrev 00000059  00000000  00000000  0000020c  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_line   00000073  00000000  00000000  00000265  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_frame  00000020  00000000  00000000  000002d8  2**2
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_str    0000004d  00000000  00000000  000002f8  2**0
                  CONTENTS, READONLY, DEBUGGING

Disassembly of section .text:

00000000 <__vectors>:
   0:  0c 94 2a 00   jmp  0x54  ; 0x54 <__ctors_end>
   4:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
   8:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
   c:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
  10:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
  14:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
  18:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
  1c:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
  20:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
  24:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
  28:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
  2c:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
  30:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
  34:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
  38:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
  3c:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
  40:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
  44:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
  48:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
  4c:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>
  50:  0c 94 3c 00   jmp  0x78  ; 0x78 <__bad_interrupt>

00000054 <__ctors_end>:
  54:  11 24         eor  r1, r1
  56:  1f be         out  0x3f, r1  ; 63
  58:  cf e5         ldi  r28, 0x5F  ; 95
  5a:  d8 e0         ldi  r29, 0x08  ; 8
  5c:  de bf         out  0x3e, r29  ; 62
  5e:  cd bf         out  0x3d, r28  ; 61

00000060 <__do_clear_bss>:
  60:  10 e0         ldi  r17, 0x00  ; 0
  62:  a0 e6         ldi  r26, 0x60  ; 96
  64:  b0 e0         ldi  r27, 0x00  ; 0
  66:  01 c0         rjmp  .+2        ; 0x6a <.do_clear_bss_start>

00000068 <.do_clear_bss_loop>:
  68:  1d 92         st  X+, r1

0000006a <.do_clear_bss_start>:
  6a:  a4 36         cpi  r26, 0x64  ; 100
  6c:  b1 07         cpc  r27, r17
  6e:  e1 f7         brne  .-8        ; 0x68 <.do_clear_bss_loop>
  70:  0e 94 3e 00   call  0x7c  ; 0x7c <main>
  74:  0c 94 75 00   jmp  0xea  ; 0xea <_exit>

00000078 <__bad_interrupt>:
  78:  0c 94 00 00   jmp  0  ; 0x0 <__vectors>

0000007c <main>:

volatile unsigned long int seconds;

int main(void)
{
  seconds = 10; //Im Debugger wird immernoch 0 anezgeigt
  7c:  8a e0         ldi  r24, 0x0A  ; 10
  7e:  90 e0         ldi  r25, 0x00  ; 0
  80:  a0 e0         ldi  r26, 0x00  ; 0
  82:  b0 e0         ldi  r27, 0x00  ; 0
  84:  80 93 60 00   sts  0x0060, r24
  88:  90 93 61 00   sts  0x0061, r25
  8c:  a0 93 62 00   sts  0x0062, r26
  90:  b0 93 63 00   sts  0x0063, r27
  while(1)
  {
    if(seconds > 0) //trift nicht zu
  94:  80 91 60 00   lds  r24, 0x0060
  98:  90 91 61 00   lds  r25, 0x0061
  9c:  a0 91 62 00   lds  r26, 0x0062
  a0:  b0 91 63 00   lds  r27, 0x0063
  a4:  00 97         sbiw  r24, 0x00  ; 0
  a6:  a1 05         cpc  r26, r1
  a8:  b1 05         cpc  r27, r1
  aa:  99 f0         breq  .+38       ; 0xd2 <main+0x56>
      seconds--;
  ac:  80 91 60 00   lds  r24, 0x0060
  b0:  90 91 61 00   lds  r25, 0x0061
  b4:  a0 91 62 00   lds  r26, 0x0062
  b8:  b0 91 63 00   lds  r27, 0x0063
  bc:  01 97         sbiw  r24, 0x01  ; 1
  be:  a1 09         sbc  r26, r1
  c0:  b1 09         sbc  r27, r1
  c2:  80 93 60 00   sts  0x0060, r24
  c6:  90 93 61 00   sts  0x0061, r25
  ca:  a0 93 62 00   sts  0x0062, r26
  ce:  b0 93 63 00   sts  0x0063, r27
    
    seconds++; //keine Änderung.
  d2:  80 91 60 00   lds  r24, 0x0060
  d6:  90 91 61 00   lds  r25, 0x0061
  da:  a0 91 62 00   lds  r26, 0x0062
  de:  b0 91 63 00   lds  r27, 0x0063
  e2:  01 96         adiw  r24, 0x01  ; 1
  e4:  a1 1d         adc  r26, r1
  e6:  b1 1d         adc  r27, r1
  e8:  cd cf         rjmp  .-102      ; 0x84 <main+0x8>

000000ea <_exit>:
  ea:  f8 94         cli

000000ec <__stop_program>:
  ec:  ff cf         rjmp  .-2        ; 0xec <__stop_program>

Ich kann leider (noch) kein Assembler aber vielleicht seht ihr ja was??

Gruß

[Julian B. (julinho)]

Der assemblercode sieht etwas merkwürdig aus, die long int variable wird 
in die register r24-r27 geladen, r25 wird allerdings nie berücksichtigt.
Hast du schon mal verschiedene Optimierungsstufen getestet?

[Rolf Magnus (Gast)]

Julian Baugatz schrieb:
> r25 wird allerdings nie berücksichtigt.

Doch, wird es. Hier z.B.:

  a4:  00 97         sbiw  r24, 0x00  ; 0
  a6:  a1 05         cpc  r26, r1
  a8:  b1 05         cpc  r27, r1

Die erste Instruktion (subtract immediate from word) subtrahiert 0 vom 
Registerpaar r24:r25, was die Registerwerte nicht ändert, aber die Flags 
wie bei einem Vergleich mit 0 setzt. Das spart eine Instruktion 
gegenüber einer Kombination aus einem cp und einem cpc. Danach wird dann 
noch ggf. ein Übertrag nach r26 und r27 weitergereicht (r1 wird vom 
Compiler als 0-Register verwendet).

Und auch hier:

  bc:  01 97         sbiw  r24, 0x01  ; 1
  be:  a1 09         sbc  r26, r1
  c0:  b1 09         sbc  r27, r1

Da wird in der ersten Instruktion das Registerpaar r24:r25 
dekrementiert.

Und hier das selbe Spiel beim Inkrementieren:

  e2:  01 96         adiw  r24, 0x01  ; 1
  e4:  a1 1d         adc  r26, r1
  e6:  b1 1d         adc  r27, r1

Also der Code sieht an sich korrekt aus.

[Thomas E. (thomase)]

cemizm schrieb:
> Wenn ich das ganze mit meinem Dragon auf dem STK500 debugge, ändert sich
> 'seconds' nie.

Wieviele Breakpoints setzt du denn?

Wenn du einen Breakpoint auf ein "seconds" setzt, ändert sich nichts, 
weil die Programmschleife im Resultat nichts macht. Setzt du auf beide 
"seconds" in der Schleife jeweils einen Breakpoint, kannst du sehen, wie 
der Inhalt von "seconds" zwischen 10 (1. "second") und 9 (2."second") 
"pendelt".

Wenn dem nicht so ist, hat entweder dein STK500 oder dein Dragon 'ne
Macke oder das Programm wurde nicht richtig übertragen. Denn der Code 
ist richtig und macht genau, was er soll.

>>seconds = 10; //Im Debugger wird immernoch 0 anezgeigt
Daß hier "0" angezeigt wird, ist vollkommen richtig, da der Debugger das 
Programm VOR der Ausführung des Befehls anhält.

Aus dem gleichen Grund bekommst du hier
>>seconds--; "10" angezeigt.

usw.


mfg.

[cemizm (Gast)]

Erstmal vielen Dank für die Hilfestellungen. Habe jetzt meinen AVR 
ausgetauscht und mit dem funktioniert es.

Hatte keinen Breakpoint gesetzt sondern zeilenweise debuggt und seconds 
im Watch gehabt.

Dennoch merkwürdig da der AVR sonst einwandfrei arbeitet??!