mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik SRAM liefert flasche Werte zurück


Autor: Paule_ (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich habe versucht ein externes RAM an meinen AT90CAN128 anzuschließen. 
Wie ich das mit dem Controller verbunden habe, ist auf dem Ausschnitt 
des Schaltplans zu sehen. Ich hab das ganze auch schon mal auf der 
Platine durchgemessen, ob irgendwo Kurzschlüsse zu finden sind oder evtl 
Pins nicht angeschlossen sind. Dabei ist mir nichts aufgefallen.
Das Problem jedoch ist, dass der RamRiegel falsche Werte zurück liefert. 
Das ganze kann man gut bei Textmeldungen über die UART sehen. Teils 
stimmen die Buchstaben und das Wort ist auch zu erkennen, aber alles in 
Allem sind duzende Buchstabendreher drin.


Also zur Technik:

Im makefile hab ich den Ramriegel so eingebunden:
# 32 KB of external RAM, starting after internal RAM
start=.data=0x801100,--defsym=__heap_start=0x804000,--defsym=__heap_end=0x808fff
Damit ist alles, außer dem Stack im externen Ram ausgelagert. Jetzt will 
ich aber noch den RAM zur Compilerzeit bekannt machen, also noch schnell 
die Register bereits im makefile setzen...
# List Assembler source files here.
# Make them always end in a capital .S.  Files ending in a lowercase .s
# will not be considered source files but generated files (assembler
# output from the compiler), and will be deleted upon "make clean"!
# Even though the DOS/Win* filesystem matches both .s and .S the same,
# it will preserve the spelling of the filenames, and gcc itself does
# care about how the name is spelled on its command-line.
ASRC = xram.S
Die xram.S sieht dann so aus:
;; begin xram.S
;; Aktivierung des externen Memory-Interfaces
#include <avr/io.h>
 .section .init1,"ax",@progbits

;;entspricht XMCRA = ((1<<SRL2) | (1<<SRW11) | (1<<SRW10) | (1<<SRE));  
 ldi r16,_BV(SRE) | _BV(SRW10) | _BV(SRW11) | _BV(SRL2)
 sts XMCRA,r16

;; end xram.S

Das sollte doch eigentlich funktionieren, oder? Also ich hab keine 
Ahnung mehr. Soweit ich mich erinnern kann, habe ich mit dieser 
Einstellung bereits die "langsamste" Betriebsart des RamRiegels gewählt. 
Daran sollte es dann auch nicht mehr liegen. Ach ja der 62256 ist von 
Conrad (15ns).


Hat jemand ne Idee? Evtl doch schon ein Fehler im Layout?

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ein 62256 -15 hat 150ns, nicht 15ns.
Ist ziemlich das langsamste, was man noch so beommen dürfte.
Allerdings habe ich auch schon 120ns Ram mit 16MHz ohne WaitStates 
stabil betrieben. Der 74HC573 dürfte dafür aber zu langsam sein, ich 
habe meist AC oder ACT drin.

Gruß aus Berlin
Michael

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atmel rät zwar zu 74AHC, aber viele Implementierungen verwenden 
erfolgreich die 74HC Version bei 16MHz.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso empfiehlt Atmel eigentlich den AC/AHC? Ich kann laut Datenblatt 
keinen einzigen Wert erkennen, der für diesen spricht. Das 
Geschwindigkeits begrenzende Kriterium ist der RD\ Impuls, der bei 16MHz 
nur rund 50ns hat.

Von AHC rate ich ab, die Dinger funktionieren nur auf einem ordentlichen 
Layout mit passender Terminierung usw. Ansonsten verursachen die mehr 
Überschwinger als sonst was. Die AC sind OK.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso empfiehlt Atmel eigentlich den AC/AHC? Ich kann laut Datenblatt
keinen einzigen Wert erkennen, der für diesen spricht.

Haben AC oder AHC kleinere Gatekapazitäten? habs nicht nachgeprüft...

Autor: Paule_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, danke schon mal für die vielen Infos. Auf der Conrad-Seite steht 
tatsächlich 15ns für den 62256 und das Datasheet ist immer noch nicht 
betrachtbar. Naja. Evtl mal eine kleine E-Mail schreiben :)

Aber zu dem 74HC:
Ich hatte schon mal einen 74HCT573 mit einem V62C518256 bei 16MHz in 
Betrieb. HC und HCT sollten doch beide bei ca. 15ns arbeiten, oder?

Meiner Meinung nach ist damit das RAM schuld. Hmm. Wieder viel Lötzeit 
fürn **** und noch mehr Lötzzeit für Aus- und Einlöten für die 
Zukunft....

Autor: was-willst-du (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi !
Frage wie ist denn Pin 20 des Ram angeschlossen ?

Vielleicht wird das Ram ja angesprochen (beschrieben), wenn Du es gar 
nicht erwartest?

Autor: Paule_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh. /E hab ich ganz vergessen. Pin20 ist mit ADR15 bzw. PC7 verbunden.

Den SRam, den ich von Conrad bekommen habe, ist in Wirklichkeit ein 
IS61C256AH-15J. Sollte laut Datenblatt 15ns schaffen. Wo liegt 
eigentlich der signifikante Unterschied zu einem 62256?

Damit weiß ich nun wieder nicht worans liegt :)

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Paule_ wrote:

> Den SRam, den ich von Conrad bekommen habe, ist in Wirklichkeit ein
> IS61C256AH-15J. Sollte laut Datenblatt 15ns schaffen. Wo liegt
> eigentlich der signifikante Unterschied zu einem 62256?

Der 61C256 ist ein Cache SRAM wie er in 486ern für den L2 Cache 
verwendet wurde. Der 62256 ist dagegen ein normaler, langsamer SRAM.
Der Geschwindigkeitsunterschied macht sich auch im Stromverbrauch 
bemerkbar.

Der 61C256 dürfte auch optisch deutlich anders aussehen als ein normaler 
SRAM: Die Cache SRAMs sind im SDIP28/29 untergebracht, die normalen 
SRAMs haben dagegen das normale, breite 28/32 DIP.
Als SMD dürften die Cache SRAMs meist SOJ haben, während die normalen 
SRAMs meist SOP haben.

Nur in TSOP sind beide erhältlich.

Autor: Paule_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...nicht nur Optik. Das Ding hat all meine Lötkünste gebraucht ;)

Autor: der mechatroniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal ne Halb-OT-Frage, weil vorhin das Layout angesprochen wurde: Wie 
layoutet ihr solche µC-Latch-SRAM-Konstrukte? Ich kann evtl. gleich mal 
mein Layout rauskramen, was ich mit überlegt hab. Kommt mir aber noch 
nicht so optimal vor...

Ich nehm an, man sollte mit den 3 ICs und allen Adress- und 
Datenleitungen mögl. auf einer Ebene bleiben?

Hat mal jemand ein Stück Layout für mich zum anschauen?

Danke im Voraus
Sebastian

Autor: Paule_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab das Ganze jetzt nochmal genauer analysiert.

Anscheinend wird immer, wenn ein Fehler beim Lesen vom SRAM oder 
vielleicht auch beim Schreiben auftritt, nur ein einzelnes Bit in einem 
Byte gedreht und das ist immer das 4-wertige.

Daraufhin habe ich nochmal die Verbindung von AD2 und auf von AD5 
geprüft aber kein Problem bzw Unterschied zu den Anderen erkannt. 
Lediglich bei AD5 am SRAM direkt mußte ich mich mit einer kleiner 
Drahtbrücke behelfen, welche aber auch an GND und ADR6 des gleichen ICS 
ähnlich verlötet ist. Die Brücke schließt nur den dort etwas großen 
Zwischenraum zwischen PAD und PIN. Leider ist mir dort einfach kein 
Lötzinn reingeflossen.

Dieses "Bittauschen" tritt aber nicht immer auf und auch in mir keinem 
erkennbaren Muster. Hat irgendjemand eine Ahnung worans leigen 
könnte????
Der Fehler ist 100%tig wiederholbar. Sprich neu Programmieren und der 
Fehler ist genauso wie vor 10 Programmiervorgängen.

Autor: Paule_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mechatroniker
welches Tool? ICh kann dir aber glaub ich nicht sonderlch weiter helfen. 
Das ist auch meine Premiere mit EAGLE

Autor: Paule_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verdammte Verschreiberei. Kann leider nichts ändern aber in meinem 
obigen Post muß es heißen:

zweiter Absatz
"[...]von AD2 und auch von AD5[...]"
"[...]Lediglich bei AD2 am SRAM direkt mußte ich mich mit einer kleiner
Drahtbrücke behelfen,[...]"

Autor: Paule_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OH NO!


Es waren tatsächlich diese 3mm Draht, die alles Zunichte gemacht haben. 
Jetzt funktioniert alles einwandfrei bzw. solange bis ich Bitdreher in 
ADR6 feststelle, da ist nämlich auf eine Brücke verbaut :)

Danke fürs miträtseln!

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

der Draht als solcher wohl weniger, eher kalte Lötstelle, weil man nicht 
richtig rankommt und zu vorsichtig ist...

Hatte ich letztens bei einem Tiny85 geschafft, die Effekte waren ähnlich 
zufällig.

Gruß aus Berlin
Michael

Autor: der mechatroniker (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal mein Layout, noch ohne Stützkondensatoren, RD und WR. Was ich 
vor allem blöd finde, ist daß zwei Leitungen aus dem Adress-High-Byte 
deutlich länger sind als alles andere. Besser bekomm ichs aber nicht. 
Deswegen wollte ich fragen, wie ihr die ICs anordnet.

Autor: Paule_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht bin ich da etws vorschnell, aber ich glaube nicht, dass du 
aufgrund der Längenunterschiede Probleme bekommst. Das sind wohl eher 
Sorgen des HF'lers.

Autor: Route_66 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mechatroniker
Zum Layout bei RAMs musst Du dir keinen Knick ins Hemde machen. Da ja 
der Prozessor schreibt und liest ist es egal, ob Adresspins 
untereinander oder Datenbits untereinander vertauscht sind. Im ersten 
Fall landet das entsprechende Byte an einer falschen Stelle, wird aber 
auch von da gelesen. im zweiten wird das Byte als falscher Wert 
geschrieben aber beim Lesen zurück"konvertiert". Probleme treten nur 
auf, wenn z.B. EPROMs, EEPROMs oder Flash-Speicher extern beschrieben 
und dann eingebaut werden.
Das hab ich aber auch schon benutzt, um komplizierte Layouts zu 
vermeiden. Muss man halt beim Programmieren entsprechend umsortieren. 
Funktioniert dann aber auch als Schutz gegen Hacker-Anfänger.

Autor: Route_66 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Upps, bei Timekeeper-RAMs natürlich auf das Auslesen der Uhr achten!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.