Ich verwende zum ersten Mal ein SDRAM (Micron 4M x 16 x 4) mit einem
STM32F7 auf meiner eigenen Platine.
Das Initialisieren scheint zu funktionieren, aber wenn ich das SDRAM
teste
1
for(uint16_ti=0;i<65535;++i){
2
*(__IOuint16_t*)(SDRAM_BASE+2*i)=i;
3
}
4
5
for(uint16_ti=0;i<65535;++i){
6
uint16_tx=*(__IOuint16_t*)(SDRAM_BASE+2*i);
7
if(x!=i)printf("Index %x read %x",i,x);
8
}
passiert dies hier:
1
Index80reada0
2
Index81reada1
3
Index82reada2
4
Index83reada3
5
Index84reada4
6
Index85reada5
7
Index86reada6
8
Index87reada7
9
Index88reada8
10
Index89reada9
11
Index8areadaa
12
Index8breadab
13
Index8creadac
14
Index8dreadad
15
Index8ereadae
16
Index8freadaf
17
Index90readb0
18
Index91readb1
19
Index92readb2
20
Index93readb3
21
Index94readb4
22
Index95readb5
23
Index96readb6
24
Index97readb7
25
Index98readb8
26
Index99readb9
27
Index9areadba
28
Index9breadbb
29
Index9creadbc
30
Index9dreadbd
31
Index9ereadbe
32
Index9freadbf
33
Indexc0reade0
34
...
und hört nicht mehr auf.
Wie man sieht, ist Bit #5 fehlerhaft immer auf 1 gesetzt, allerdings
auch erst ab Wort-Adresse 0x80!?
Ich habe noch mit Adressverschiebung getestet, da trat der Fehler
trotzden an der gleichen Adresse auf. Es handelt sich also um einen
Fehler im Adressbus, nicht im Datenbus.
Trotzdem weiß ich nicht, welche Art Fehler dieses Verhalten verursachen
kann. Laut Adress-Decoding wäre es Column-Bit 4. Die Platine habe ich
schon untersucht und keine Lötfehler festgestellt.
Jemand ne Theorie zur Fehlerursache?
ral schrieb:> und keine Lötfehler festgestellt.
Dann suche nochmal mit dem Osziloskop ob der Refresh es
schafft die betreffende Adressleitung zu betätigen. Könnte
ja trotz fehlendem Lötfehler ein Kurzschluss eingebaut sein.
Fern Schätzer schrieb:> Timing Einstellungen zu progressiv gewählt?
Eigentlich eher konservativ, d.h. alle Timings zu hoch. CL und Refresh
stimmen aber.
> (Address-/Daten-) Leitungsführung schlampig?
Im Zeifel natürlich ja. :-) Ich habe aber extra vier Lagen benutzt, und
peinlichst auf Länge, Abstände und Verteilung auf Lagen geachtet.
Bei Leitungsproblemen hätte ich eher Zufall erwartet (wenn es überhaupt
funktioniert).
Fern Schätzer schrieb:> Dann suche nochmal mit dem Osziloskop ob der Refresh es> schafft die betreffende Adressleitung zu betätigen. Könnte> ja trotz fehlendem Lötfehler ein Kurzschluss eingebaut sein.
Genau sowas möchte ich gerne vermeiden. :-) Aber ist natürlich richtig;
ich verstehe davon momentan nur zu wenig,
prennz schrieb:> Eigentlich eher konservativ, d.h. alle Timings zu hoch. CL und Refresh> stimmen aber.
Und hast du geprüft ob bei initialisiertem Controller der
laufende Refresh auf allen Leitungen "etwas tut"?
Fern Schätzer schrieb:> Dann suche nochmal mit dem Osziloskop ob der Refresh es> schafft die betreffende Adressleitung zu betätigen. Könnte> ja trotz fehlendem Lötfehler ein Kurzschluss eingebaut sein.
prennz schrieb:> ich verstehe davon momentan nur zu wenig,
Ob die Leitung "wackelt" oder statisch auf einem Pegel
bleibt wirst du ja gerade noch unterscheiden können.
Möglicherweise liegt auch ein Fehler in der Bauteilebibliothek des
Leiterplatten-CAD vor, d.h. mindestens ein Pin des Microcontrollers oder
RAMs ist falsch belegt. Leider erlebt man solch einen Pfusch auch bei
Bibliotheken , die von den Halbleiterherstellern bereitgestellt werden,
wie ich unlängst schmerzhaft erfahren durfte. Man darf sich also nicht
darauf verlassen, die so etwas erprobt, d.h. z.B. auf einem
herstellereigenen Entwicklungsboard eingesetzt wurde.
Passen denn die zulässigen Versorgungsspannungen und Signalpegel von
Microcontroller und SDRAM überhaupt zusammen? Wurden die richtigen
SDRAMs eingelötet? Vor einigen Jahren hatten wir das Problem, dass
Entwicklungsboards immer wieder Speicherfehler produzierten. Nach
mehrwöchiger Fehlersuche fand ich heraus, dass bei einigen dieser
3,3V-Boards fälschlicherweise RAMs für 5V bestückt waren.
Und ein anderer Kunde suchte monatelang Fehler im Netzwerkstack seines
Embedded Linux, und ihm fiel nicht auf, dass bei den betroffenen,
fehlerhaften Netzwerkpaketen immer nur zwei Bits betroffen war, nämlich
(n) und (n+16). Ich warf einen kleinen Blick auf das Layout und sah
sofort, dass die Datenleitung (n) des externen 16 Bit breiten DDRAMs
wesentlich umständlicher geführt war als die anderen 15 Bit. Der
zuständige Hardwerker bestand anfangs immer noch darauf, schon seit über
zwanzig Jahren seine Leiterbahnen so zu verlegen und es habe noch nie
Probleme gegeben. Das stimmte ja auch: die uralten Produkte mit externem
Speicher wurden ja mit weniger als 10MHz getaktet und die neueren hatten
alle nur internen Speicher. Und bei dem 400 MHz-Prozessor mit externem
DDRAM gab es dann eben die Probleme...
Andreas S. schrieb:> Passen denn die zulässigen Versorgungsspannungen und Signalpegel von> Microcontroller und SDRAM überhaupt zusammen?
Ja, richtig. Dann darf man auch noch fragen ob denn ausreichend
Abblock-Kondensatoren für das SDRAM vorgesehen wurden und ob die
Leitungen dafür korrekt verlegt sind.
Denn wenn ich das höre:
prennz schrieb:> Genau sowas möchte ich gerne vermeiden. :-) Aber ist natürlich richtig;> ich verstehe davon momentan nur zu wenig,
... dann wird mir leicht schwindelig ....
prennz schrieb:> Irgendwas geht da schief, unabhängig von Bit 5. Ich schaue es mir mit> dem Oszilloskop an.
Wie bitte? Du hast das Verhalten vorher noch nicht mit dem Oszilloskop
kontrolliert? I break together.
Fern Schätzer schrieb:> Ja, richtig. Dann darf man auch noch fragen ob denn ausreichend> Abblock-Kondensatoren für das SDRAM vorgesehen wurden und ob die> Leitungen dafür korrekt verlegt sind.
Ich habe alles das gemacht, was im Datenblatt steht.
> Denn wenn ich das höre:> ... dann wird mir leicht schwindelig ....
Was aber nicht im Datenblatt steht, müßte ich mir erst aneignen. Als
Hobbyist darf man das so machen.
Andreas S. schrieb:> Wie bitte? Du hast das Verhalten vorher noch nicht mit dem Oszilloskop> kontrolliert? I break together.
Bei dem Zustandsdiagramm fange ich lieber vorne an.
prennz schrieb:> Ich habe alles das gemacht, was im Datenblatt steht.
Im Datenblatt steht meistens nicht drin wie man im Layout
Leitungen (speziell der Abblock-Kondensatoren) verlegt.
prennz schrieb:> darf man das so machen
Man darf alles machen, muss aber mit den Konsequenzen leben
(können), insbesondere potentiell Meckereien hier im Forum
ertragen ....
prennz schrieb:> Ich habe alles das gemacht, was im Datenblatt steht.
Aber dann schau dir doch bitte auch an, wie das z.B. auf den Discovery
Boards gemacht wird, z.B. dem STM32F429 Disco.
Für die Boards gibt es Layout und Schaltplan.
Also gut, vom Layout habe ich auf die Schnelle nur einen Screenshot,
aber man sieht grob den Leitungsverlauf und die Kondensatoren. Alles in
Gruppen, verschiedene Layer, alles +- 10mm von CLK, Abstände von min.
5mm zwischen Gruppen auf selbem Layer.
Das Layout ist eher einfach, alle Pins sind mit den entsprechenden des
FMC verbunden. Als Code siehe Beispiel.
Ich habe nochmal die Testsequenz ausprobiert und etwas Unerfreuliches
festgestellt. Mit
1
for(uint16_ti=A;i<B;++i){
2
*(__IOuint16_t*)(SDRAM_BASE+2*i*0x10)=i;
3
}
4
for(uint16_ti=A;i<B;++i){
5
uint16_tx=*(__IOuint16_t*)(SDRAM_BASE+2*i*0x10);
6
printf("Index %x read %x %d",i,x,i==x);
7
}
und unterschiedlichen Werten A und B erhalte ich in getrennten Läufen
1
Indexdreadd1
2
Indexereade1
und
1
Indexereade1
2
Indexfreadf1
und
1
Indexdreadd1
2
Indexereade00<-------------
3
Indexfreadf1
d.h. der Fehler hängt von den umgebenden Zugriffen ab. Außerdem ist der
gelesene Wert um den Faktor 0x10 zu groß, also genauso zu groß, wie ich
die Adresse "gestreckt" habe. Wenn ich auf 0x100 vergrößere, werden auch
die falschen Werte um diesen Faktor größer.
Der gelesene Wert sollte gar nicht im SDRAM vorhanden sein. Da sich die
Adresse auf den Wert auswirkt, muß ziemlich was verkorkst sein.
Fern Schätzer schrieb:> Aha, plötzlich hat der TO einen anderen Namen?
@ral und prennz: sieh dir mal die Nutzungsbedingungen an. Da steht:
nur 1 Name pro Thread! Bitte in Zukunft dran halten.
Hallo,
ich kenne den RAM-Test so dass man das RAM zuerst mit 0xAA beschreibt
und zurück liest und danach mit 0x55 um Bitfehler zu erkennen.
Bei Dir wäre das dann 0xAAAA bzw. 0x5555
Ciao
prennz schrieb:> Ich habe noch ein zweites Board gelötet, gleiche Fehler.
Jetzt baue noch drei Boards auf und finde die gleiche
Symptomatik. Schöne Fleissarbeit, wenigstens bist du damit
gut beschäftigt und kommst nicht auf dumme Gedanken.
Und du schaffst es nicht einfach einmal alle Adressleitungen
und Datenleitungen der Reihe nach abzuklappern ob sie sich
bewegen und auf definiertem Pegel (nämlich 0 oder 3.3V, nicht
dazwischen) liegen?
Wenn du solche einfache Tipps ignorierst bzw nicht dazu in der
Lage bist so etwas auszuführen dann mache irgendwas anderes,
aber nicht Mikrocontroller bauen.
Im Layout ist übrigens nicht zu erkennen wie Vcc und Gnd
verbunden werden. Wie soll man sich da seinen Reim machen...
Hans schrieb:> ich kenne den RAM-Test so dass man das RAM zuerst mit 0xAA beschreibt> und zurück liest und danach mit 0x55 um Bitfehler zu erkennen.
Das Problem bei diesem simplen Test ist, dass man dann kurzgeschlossene
Adressleitungen nicht erkennt. Im Prinzip könnten da sogar sämtliche
Adressleitungen beliebig kurzgeschlossen sein, weil ja an jeder Adresse
das selbe steht...
Insofern ist das Beschreiben von Speicherzellen mit einem hochlaufenden
Zähler wesentlich besser.
Und noch besser wird er, wenn der Zähler für die Daten hoch- und der für
die Adresse runter läuft.
Und noch deutlich besser wird der Test, wenn ins RAM an die eine Adresse
ein Zufallswert und an eine andere Speicher (mit komplett anderer
Adresse, am besten mit einem ungeraden Offset) sein Zweierkomplement
geschrieben wird. Diese beiden gespeicherten Werte werden dann beim
Vergleich einfach aufsummiert und mit 0 verglichen...
Lothar M. schrieb:> Das Problem bei diesem simplen Test ist, dass man dann kurzgeschlossene> Adressleitungen nicht erkennt. Im Prinzip könnten da sogar sämtliche> Adressleitungen beliebig kurzgeschlossen sein, weil ja an jeder Adresse> das selbe steht...
Richtig.
Aber es geht ja zunächst einmal darum zu erkennen ob die Datenleitungen
ok sind.
Danach gibt es mehrere Strategien um Adressfehler heraus zu finden.
Happy Hunting.
Ciao
Fern Schätzer schrieb:> Und du schaffst es nicht einfach einmal alle Adressleitungen> und Datenleitungen der Reihe nach abzuklappern ob sie sich> bewegen
Das habe ich aus dem erfolgreichen sequentiellem Byte-Test geschlossen,
zumindest für alle Signale außer DQ8-15.
> und auf definiertem Pegel (nämlich 0 oder 3.3V, nicht> dazwischen) liegen?
Das wußte ich nicht.
Also habe ich nun mein Oszi genommen und kann Dir bestätigen, es wackeln
ALLE Signalleitungen, und zwar scharf zwischen 0 und 3.3 V.
> Im Layout ist übrigens nicht zu erkennen wie Vcc und Gnd> verbunden werden. Wie soll man sich da seinen Reim machen...
Im Moment benutze ich ein Labornetzgerät und habe 3.3V und GND per Pin
an Vdd und Vss angeschlossen. Es gibt Planes für Vdd und Vss auf versch.
Layern, aber die habe ich der Übersichtlichkeit wegen ausgeblendet. Vcc?
Andreas S. schrieb:> In Deinem Layout ist Pin 23 (A0) des SDRAMs überhaupt nicht> angeschlossen. Wie willst Du denn da einwandfreie Signalpegel> festgestellt haben?
Das habe ich bei Inspektion gemerkt und korrigiert.
prennz schrieb:> Andreas S. schrieb:>> In Deinem Layout ist Pin 23 (A0) des SDRAMs überhaupt nicht>> angeschlossen. Wie willst Du denn da einwandfreie Signalpegel>> festgestellt haben?>> Das habe ich bei Inspektion gemerkt und korrigiert.
Ist mir ehrlich gesagt ein Rätsel, wie Kicad das durchrutschen ließ.
prennz schrieb:> Das habe ich bei Inspektion gemerkt und korrigiert.
Na super, dann hat also das publizierte Layout fast nichts mit dem
tatsächlich gefertigten zu tun. Und wir sollen uns hier die Mühe machen,
Deine vorsätzlich fehlerhafte Schaltung zu inspizieren?
Andreas S. schrieb:> Na super, dann hat also das publizierte Layout fast nichts mit dem> tatsächlich gefertigten zu tun.
"Fast nichts" ist das genaue Gegenteil des Wahren.
> Und wir sollen uns hier die Mühe machen,> Deine vorsätzlich fehlerhafte Schaltung zu inspizieren?
Nein, laßt gut sein.
prennz schrieb:> "Fast nichts" ist das genaue Gegenteil des Wahren.
Die Tatsache, dass ich auf Anhieb einen wirklich funktionsrelevanten
Unterschied gefunden habe, belegt meine Aussage doch ganz klar.