SRAM-Belegung ATmega32

Hallo zusammen,
ich habe gerade angefangen, ein 2 Jahre liegengelassenes Projekt mit 
einem ATmega32 wiederaufzunehmen. Um eine Übersicht über den 
Speicherbereich zu machen habe ich eine kleine SRAM-Dump-Funktion 
geschrieben, die mir den Inhalt des SRAMs direkt auf dem angeschlossenen 
Grafik-LCD ausgibt.

Da das Grafik-LCD nur 128x64 Pixel hat, muß ich das Ganze natürlich auf 
zwei "Bildschirmseiten" aufteilen. Um deuten zu können welche Bereiche 
vom Programm überhaupt angetastet wurden, wird der SRAM vorher, soweit 
möglich, mit 0xAAs geflutet, gemäß dem Artikel:

 http://www.rn-wissen.de/index.php/Speicherverbrauch_bestimmen_mit_avr-gcc

Auf den Fotos oben sieht man die angezeigte Belegung auf dem GLCD. 
Konkret wundert mich der Anfang der zweiten Hälte: Ist das realistisch, 
wenn ja: Woher mag diese Belegung kommen, oder müssen das Artefakte 
aufgrund der Anzeige sein?

Nochfolgend der Quelltext der Anzeigefunktion. Ich denke, die 
Funktionsnamen sind selbsterklärend, ansonsten die Erklärung danach.

Viele Grüße
Nicolas

-----

1

/* Menuehilfsfunktionen: Darstellung des SRAM-Inhalts als Pixelmuster */

2

// Kompletten SRAM, so weit erlaubt, mit 0xAA fuellen, um den vom Programm angetasteten

3

// Bereich sichtbar zu machen (komplett aus Artikel uebernommen)

4

#define MASK 0xaa

5

void __attribute__ ((naked, used, section(".init3"))) init_mem (void);

6

void init_mem (void)

7

{

8

  __asm volatile (

9

  "ldi r30, lo8 (__heap_start)"  "\n\t"

10

  "ldi r31, hi8 (__heap_start)"  "\n\t"

11

  "ldi r24, %0"                  "\n\t"

12

  "ldi r25, hi8 (%1)"            "\n"

13

  "0:"                           "\n\t"

14

  "st  Z+,  r24"                 "\n\t"

15

  "cpi r30, lo8 (%1)"            "\n\t"

16

  "cpc r31, r25"                 "\n\t"

17

  "brlo 0b"

18

  :

19

  : "i" (MASK), "i" (RAMEND+1)

20

  );

21

}

22

23

24

/* Darstellung der Speicherbelegung (SRAM) des ATmega32 als Pixelmuster auf dem GLCD

25

 * Da da Display nur 1k darstellen kann, warten auf Tastendruck und Darstellung der

26

 * zweiten Haelfte */

27

extern unsigned char __heap_start; // From linker script

28

29

void menu_memdump(){

30

  unsigned char *p = &__heap_start;

31

32

  glcd_clear();

33

  glcd_abspos(0);

34

  for (uint8_t *i = (int *) 0;i < (int *) 1024;i++) {

35

    glcd_putdat(*i);    

36

  }

37

38

  while(!getkeystroke());

39

40

  glcd_clear();

41

  glcd_abspos(0);  

42

  for (uint8_t *i = (int *) 1024;i < RAMEND;i++) {

43

    glcd_putdat(*i);

44

  }

45

46

  while(!getkeystroke());

47

}

----
glcd_clear leert das Display,

glcd_abspos setzt den Cursor auf die erwartete Stelle (0 bis 1024), die 
Displayfunktionen sind so geschrieben, daß die Position linear ist und 
automatisch auf dem richtigen KS0108 an der richtigen Stelle landet.

glcd_putdat fügt das Bitmuster auf das Display (linear zeilenweise über 
das ganze Display)

getkeystroke liefert 1 zurück, wenn ein Taster gedrückt wurde, ansonsten 
0.

----
P.S.: Nicht über den schlechten Kontrast wundern. Das Display hat noch 
die Schutzfolie.

P.P.S: Hab's gerade gefunden. Ist ein Artefakt. RAMEND ist groesser als 
2048. Ich lasse es aber trotzdem mal stehen, falls nochmal jemand auf 
das gleiche Problem stößt.