Ram Test mit komischem Ergebnis

Paule_ Gast #1148446 
Hallo,

vor kurzem hatte ich Probleme mit meinem ext. RAM (32kx8). Daher wollte 
ich ein kleines Testprogramm schreiben, welches mir mal mitteilt, wann 
ein Schreib-/Lesefehler auftritt.
Dazu reserviere ich Speicherblöcke der Größe sizeof(char)*x mittels 
malloc(). Danach schreibe ich Werte hinein, lese diese wieder und schaue 
ob da was im Argen lag. Der Block wird wieder frei gegeben, x wird 
inkrementiert und das ganze beginnt wieder von vorn. Ist nicht besonders 
schön, aber einfach :)
Nun kam bei der Sache herraus, dass nach 10238 reserveirten Bytes ein 
Fehler auftrat. Komisch finde ich bei dieser Zahl nur, dass das ziemlich 
die Hälfte meines reservierten Heaps darstellt:
--defsym=__heap_start=0x804000,--defsym=__heap_end=0x808fff
Außerdem war es ein Schreib-/Lesefehler und kein Fehler bei der 
Reservierung des Speicherblocks.

Mein Verdacht viel auf eine weiter kalte Lötstelle bei einem Adresspin. 
Falls ich also zu heap_start die 10238 Byte hinzurechne komme ich auf 
die Adresse 0x806801, welche keinen signifikaten Sprung in der binären 
Adresse aufweißt. Ich bin mir aber auch nicht sicher, ob man das so 
rechnen darf. Ich lasse mir von meinem Testprog auch die Adresse des 
reservierten Speicherblockes zurückgeben, welche beim Abbruch dez 10238 
ist. Aber was zeigt mir diese Adresse? Einen Ort nach heap_start, also 
10238 + 0x804000?

Generell frage ich mich, ob dieses Verhalten noch normal ist, oder ob da 
wirklich noch wo der Wurm drin ist?


PS: mein anderer Beitrag 
Beitrag "SRAM liefert flasche Werte zurück"
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Langsamer Modus Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Melden Danke
Knut B. (Firma: TravelRec.) Persönliche Seite #1148548 
Ist es nicht einfacher, alle Lötstellen zu überprüfen? Neue SRAMs sind 
in aller Regel zu 100% in Ordnung. Bei ausgelöteten oder sehr alten 
SRAMs kann es schon mal zu Merkwürdigkeiten kommen. Wichtig ist 
außerdem, daß die Betriebsspannung des SRAMs innerhalb der 
Spezifikationen liegt und das Schnittstellen-Timing genau eingehalten 
wird.
Antwort Zitieren Bearbeiten Löschen Melden Danke
oszi40 Gast #1148735 
Auch wenn alle RAMs vom Werk aus "in Ordung" sind, könnte z.B. noch eine 
Zinnperle auf der Schaltung liegen.

Speicherfehler sind zwar selten geworden, aber gerade in den ersten 
Tagen nach der Montage kann man Frühausfälle häufiger beobachten. 
Deshalb ist ein kleiner Test nach der Bestückung immer lobenswert.
Antwort Zitieren Bearbeiten Löschen Melden Danke
Sepp Gast #1150749 
Also diesen blöden Riegel hab ich jetzt schon 2 oder drei mal 
nachgelötet und des öfteren dessen Anschlüsse geprüft. Aber der Fehler 
bleibt.

Also nach mehreren Testläufen ist immer der Fehler bei 10238 Byts 
Blöckgröße aufgetreten. Da ich sonst keinen malloc Befehl ausführe, gehe 
ich davon aus, dass der Heap soweit leer ist. Also geht irgendwas bei 
der Speicheradresse von 0x8038FE schief.
Rein binär sollte bei der Adresse kein Bit gesetzt worden sein, welches 
vorher nicht auch schon mal gesetzt war und zu keinem Fehler geführt 
hat. Daher würde ich schon mal die Adressleitungen ausschließen. Die 
Datenleitungen könnens aber auch nicht sein, da ja bis dahin immer alles 
passte.
-> bin ratlos

Jetzt löte ich nochmal alles nach....
Antwort Zitieren Bearbeiten Löschen Melden Danke
Paule_ Gast #1151076 
Hier mal mein Testprogramm. Evtl ist ja da der Wurm drin:

1
int main(void)

2
{

3
  init_hardware();

4
  uart1_init();

5
  char *pHeap;

6
  char *zeichen = "X";

7
  unsigned int size = 1;

8
  unsigned int isize = 0;

9
  rs232_puts("Initialisierung des Boards erfolgreich.");

10
  LED_RT(0);

11
  LED_GE(0);

12
  LED_GN(1);

13


14
  rs232_puts("Schreibe Werte in Heap. Bitte warten...");

15


16
  while(1)

17
  {

18
    //gelbe und rote LEDs blinken

19
    static uint16_t ledcnt,t;

20
    ledcnt++;

21
    if(ledcnt%100 == 0)

22
    {

23
      t=!t;

24
      LED_GE(t);

25
      LED_RT(t);

26
      

27
    }

28
    

29
                //Speicher reservieren

30
    pHeap = malloc(size);

31
    if(pHeap == 0){

32
      rs232_puts("malloc = 0");

33
      goto end;

34
    }

35
    

36
                //Beschreiben

37
    while(size!=isize){

38
      memcpy(pHeap+isize,zeichen,1);

39
      isize++;

40
    }

41
    isize=0;

42
    

43
                //Lesen

44
    while(size!=isize){

45
      if(memcmp(pHeap+isize,zeichen,1)!= 0){

46
        rs232_puts("ungleich");

47
        rs232_puts("Inhalt:");

48
        rs232_putcn(pHeap,isize+10); //evtl gibts ja noch was zu sehen

49
        goto end;

50
      }

51
      isize++;

52
    }

53
    isize=0;

54
      

55
    size++;

56
    free(pHeap);

57
  }

58
  end:

59
  rs232_puts("Abgebrochen bei einer Blockgroesse von:");

60
  rs232_puti((int)size);

61
  rs232_puts("Adresse:");

62
  rs232_puti((int)pHeap);

63


64
  return 0;

65
}
Antwort Zitieren Bearbeiten Löschen Melden Danke
Thread beobachten

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 17 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Dein Name und deine E-Mail-Adresse

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.