Externes SRAM Problem:

[Andreas Paulin (Gast)]

So. Und nun hab ICH ein SRAM-Problem:

ATMEGA128, 128kB externes SRAM angeschlossen wie im Datenblatt 
beschrieben,
AVRStudio4.12 mit GCC.....

Problem:
1. Das externe Ram ist nicht ansprechbar, seltsamerweise sind die #WR 
und #RD-Leitungen tot (=immer high).
2. Im ExRAM angesprochene Speicherzellen liefern immer das LSB der 
ADRESSE, nicht den Inhalt.

Das Posting
Beitrag "Externes Speicherinterface Hintergrundwissen"
habe  ich genau studiert. Eigentlich steht alles drin.... istz 
eigentlich genau mein Fall.
Nur funktionierts bei mir nicht.
Hier der Code in Auszügen:

Linker options:
-Wl,--defsym=__heap_start=0x801100,--defsym=__heap_end=0x80ffff
-> Dynamische Variable/Heap im ExRAM

Header:
#include  <stdlib.h> // malloc()&co.

In main() wird IOInit() aufgerufen. Dort steht:
//////////////////////////////////////////////////////////
// Init externes Ram 4k..64K:
// ohne Waitstates:
// MCUCR |= _BV(SRE);  // Bit 7: SRE SRAM Enable =1
// XMCRA = 0x00;    //
// XMCRB = _BV(XMBK);  //
// mit Waitstates:
MCUCR |= (1<<SRE)|(1<<SRW10);
XMCRA |= (1<<SRW11);        // the number of wait-states
XMCRB |= (1<<XMBK);

So. sollte eigenlich laufen. Folgende Testroutine:

unsigned char   *pExRam;
.
.
.
case 29:  // EXTRAM check
for (pExRam = __malloc_heap_start;pExRam < __malloc_heap_end;pExRam++)
   {
    printf ("\n\rXR Adr: %04Xh",pExRam);
    *pExRam=0x55;      // Speicherzelle auf'01010101'
    if (*pExRam!=0x55)
  printf (" %04Xh != 55h; ",*pExRam);
    else
  printf (" - OK");
    *pExRam=0xAA;      // Speicherzelle auf'10101010'
    if (*pExRam!=0xAA)
  printf (" %04Xh != AAh; ",*pExRam);
    else
  printf (" - OK");
  }
break;

Es funktioniert aber nicht. Auf RS232 kommt folgende Ausgabe:
"
ExRAM-Check. HeapStart: 0x1100, heap end:0xffff
XR Adr: 1100h 0000h != 55h;  0000h != AAh;
XR Adr: 1101h 0001h != 55h;  0001h != AAh;
XR Adr: 1102h 0002h != 55h;  0002h != AAh;
.
.
.
"

Und hier nochmal das
Problem:
1. Das externe Ram ist nicht ansprechbar, seltsamerweise sind die #WR 
und #RD-Leitungen tot (=immer high).
2. Im ExRAM angesprochene Speicherzellen liefern immer das LSB der 
ADRESSE, nicht den Inhalt.

Hat jemand eine Idee?

[Uhu U. (uhu)]

Bist du denn sicher, daß die Hardware keinen Fehler hat?

[Andreas Paulin (Gast)]

@ Uhu: Gute Frage!
Habe meine #RD und WR#-Signale NOCHMAL gecheckt. Diesmal mit dem DSO 
überprüft.
Nicht dran gedacht, dass die Kiste mit 16MHz so schnell ist, dass man 
die Signale im 200ns-Bereich suchen muss... hab sie jetzt am Portpin 
gefunden und sie kommen NICHT am SRAM an.
-> Erstmal Hardware checken! Thanx, Uhu!

[Andreas Paulin (Gast)]

So. Jetzt sind alle 16 A/D-Leitungen, außerdem
ALE, #WR und #RD definitiv korrekt angeschlossen. Alles gecheckt.

Aber trotzdem: Immer noch gleiches Ergebnis:

ExRAM-Check. HeapStart: 0x1100, heap end:0xffff
XR Adr: 1100h 0000h != 55h;  0000h != AAh; 
XR Adr: 1101h 0001h != 55h;  0001h != AAh; 
XR Adr: 1102h 0002h != 55h;  0002h != AAh; 
XR Adr: 1103h 0003h != 55h;  0003h != AAh;

Als Inhalt der Speicherzelle wird das LSB der Adresse zurückgegeben.


Also:
- Der Linker hats gesagt bekommen: Heap im ExtRAM
- Interface ExtRAM ist aktiviert
- 2 Waitstates sind auch eingeschaltet
- alle Leitungen zappeln, keine Schlüsse

Aber es funktioniert falsch. Irgendwo hab ich was übersehen.
Sieht jemand, was ich nicht sehe?

[Matthias L. (Gast)]

>Als Inhalt der Speicherzelle wird das LSB der Adresse zurückgegeben.

Das klingt so, als ob das Adresslatch-Ausgang an den Dateneingang des 
RAMS angeschlossen ist...?

Poste doch mal deine Schaltung. Also keinen Link, was du nachgebaut 
hast, sondern eine eigene Skizze des Planes..

[Jörg W. (dl8dtl) (Moderator)]

Außerdem: ist das Latch schnell genug?

[Andreas Paulin (Gast)]

@lippy:
Hört sich plausibel an. Ich habe mal CPU und SRAM als PDF angehängt. Das 
ist die von mir verwendete Schaltung. Kann halt keinen Fehler finden, 
ist die gleiche Standardanbindung wie bei den 8051-Controllern.
@Jörg: Ich habe kein AC sondern ein HC-Latch verwendet.
Dachte, mit Waitstates kann ichs erstmal damit laufen lassen.
Es könnte aber sein, dass die Adress Hold Time
"• Data (address) hold time after low (TH)."
 des AVR für das Latch zu kurz ist; DIE lässt sich nämlich nicht über 
Waitstates beeinflussen.
AVR-Datasheet garantiert min. 5ns.........
Bekomme halt kein Datenblatt für das hier verwendete Motorola 
HC573-Latch.... Philips-Datasheet HC573 sagt was zwischen 5ns(HC) und 
15ns(HCT),

Also, bevor wir Kristallkugeln und den Kaffeesatz bemühen, werde ich 
doch erstmal ein AHC573-Latch an den Start bringen..
Ich sag dann, wie's war :-)

[Andreas Paulin (Gast)]

@Jörg: Vergessen: Der AVR läuft schon mit 16MHz, von daher... ich schau 
mal nach AHC573....

[Matthias L. (Gast)]

>Es könnte aber sein, dass die Adress Hold Time

Glaub ich nicht, ich habe auch schon erfolgreich ein 74HC573 als 
Addresslatch an einem Atmega128 eingesetzt. Läuft bestens. Gab nie 
Probleme beim Latch.

Würd sagen, das ist was anderes..
Verdrahtungsfehler vielleicht??

[Falk B. (falk)]

@  Andreas Paulin (Gast)

> Vergessen: Der AVR läuft schon mit 16MHz, von daher... ich schau
>mal nach AHC573....

Nein, takte den lieber mal mit 1 MHz, dann kanst du sicher sagen obs am 
Latch liegt oder nicht.
Z.B. interner RC Oszillator.

MfG
Falk

[Andreas Paulin (Gast)]

@Falk HandVornKopfKlatsch Danke!
Das ist natürlich schneller, als neue ICs bestellen. Werd gleich mal die 
Fuses umstricken......

[Andreas Paulin (Gast)]

OK, alles in Butter - ich habs:
Der SRAM 628128 hat ZWEI ChipSelects statt einem.
Ich habe beim Erstellen des Bibliothekssymbols (vom guten alten 62256 
abgeleitet) übersehen, dass der 2. Chipselect auf Pin 30 im Gegensatz 
zum ersten auf Pin 22 active high(!) ist.

->CS2 von Gnd auf Vcc umgeklemmt: Geht voll gut :)
->Takt wieder auf 16MHZ und ab gehts wie Schmidts Katze :))
->Auch mit HC573: Ohne Probleme (werden aber für die Zukunft trotzdem 
AHC573 verwenden)

Vielen Dank an alle!

[Matthias L. (Gast)]

Hi Hi