[STM32] SDRAM Adressbit 5 steckt (meistens) fest

[ral (Gast)]

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

for (uint16_t i = 0; i < 65535; ++i) {
    *(__IO uint16_t*) (SDRAM_BASE + 2*i) = i;
}

for (uint16_t i = 0; i < 65535; ++i) {
    uint16_t x = *(__IO uint16_t*) (SDRAM_BASE + 2*i);
    if (x != i) printf("Index %x read %x", i, x);
}

passiert dies hier:

Index 80 read a0
Index 81 read a1
Index 82 read a2
Index 83 read a3
Index 84 read a4
Index 85 read a5
Index 86 read a6
Index 87 read a7
Index 88 read a8
Index 89 read a9
Index 8a read aa
Index 8b read ab
Index 8c read ac
Index 8d read ad
Index 8e read ae
Index 8f read af
Index 90 read b0
Index 91 read b1
Index 92 read b2
Index 93 read b3
Index 94 read b4
Index 95 read b5
Index 96 read b6
Index 97 read b7
Index 98 read b8
Index 99 read b9
Index 9a read ba
Index 9b read bb
Index 9c read bc
Index 9d read bd
Index 9e read be
Index 9f read bf
Index c0 read e0
...

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?

[Fern Schätzer (Gast)]

ral schrieb:
> Jemand ne Theorie zur Fehlerursache?

Timing Einstellungen zu progressiv gewählt?

(Address-/Daten-) Leitungsführung schlampig?

[Pete K. (pete77)]

Ist das nicht zu klein? __IO uint16_t

[Fern Schätzer (Gast)]

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.

[prennz (Gast)]

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).

[prennz (Gast)]

Pete K. schrieb:
> Ist das nicht zu klein? __IO uint16_t

Nein, das SDRAM ist x16.

[prennz (Gast)]

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,

[Fern Schätzer (Gast)]

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.

[Fern Schätzer (Gast)]

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.

[Fern Schätzer (Gast)]

Aha, plötzlich hat der TO einen anderen Namen?

Forums-Cops wo seid ihr?

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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...

[prennz (Gast)]

Noch eine Ergänzung. Ich habe beide Adressen oben jeweils mit 0x100 
multipliziert

(SDRAM_BASE + 2*i * 0x100)

und erhalte nun

Index 0 read 20
Index 1 read 120
Index 2 read 220
Index 3 read 320
Index 4 read 420
...
Index ff read ff20
Index 100 read 20
Index 101 read 120
Index 102 read 220
Index 103 read 320
...

Irgendwas geht da schief, unabhängig von Bit 5. Ich schaue es mir mit 
dem Oszilloskop an.

[Fern Schätzer (Gast)]

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 ....

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[prennz (Gast)]

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.

[prennz (Gast)]

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.

[Fern Schätzer (Gast)]

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 ....

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

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.

[Harald (Gast)]

Schaltplan, Layout & Quelltext sind das Minimum, das du posten musst.

[prennz (Gast)]

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

for (uint16_t i = A; i < B; ++i) {
    *(__IO uint16_t*) (SDRAM_BASE + 2*i * 0x10) = i;
}
for (uint16_t i = A; i < B; ++i) {
    uint16_t x = *(__IO uint16_t*) (SDRAM_BASE + 2*i * 0x10);
    printf("Index %x read %x %d", i, x, i == x);
}

und unterschiedlichen Werten A und B erhalte ich in getrennten Läufen

Index d read d 1
Index e read e 1

und

Index e read e 1
Index f read f 1

und

Index d read d 1
Index e read e0 0      <-------------
Index f read f 1

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.

[prennz (Gast)]

Das war offensichtlich ein Versehen.

[prennz (Gast)]

Ich habe noch ein zweites Board gelötet, gleiche Fehler.

[Hans (Gast)]

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

[Fern Schätzer (Gast)]

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...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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...

[Hans (Gast)]

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

[prennz (Gast)]

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. (Firma: Schweigstill IT) (schweigstill)]

In Deinem Layout ist Pin 23 (A0) des SDRAMs überhaupt nicht 
angeschlossen. Wie willst Du denn da einwandfreie Signalpegel 
festgestellt haben?

[prennz (Gast)]

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 (Gast)]

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ß.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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?

[prennz (Gast)]

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.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.