STM32F407 Fatfs mounting error

[Julian H. (julianh)]

Hi,

es wird ein STM32F407 benutzt, das ganze in Verbindung mit dem Discovery 
Board worauf ein SD-Card Reader über den dafür vorgesehenen 
SPI-Anschluss angeschlossen ist. Als Library wird fatfs benutzt.

Dabei enstehen sehr merkwürde Fehlerbilder beim Mounten.

Angefangen hatte es damit, dass die SD Karte im Büro einwandfrei 
gemountet wurde, saß man allerdings im Auto kam beim Mounten fast immer 
ein Error und man musste beim mounten mit dem Finger den 3.3v mit dem 
MISO Pin überbrücken, dann gings. Der Fehler tauchte, wenn ich mich 
recht erinnere beim disk_initialize Aufruf auf.

Das Problem wurde so gelöst, dass man vor dem Mounten einmal den MISO 
Pin auf HIGH setzt und nach dem Mounten wieder auf LOW, das hat diesen 
Fehler behoben und das Mounten klappt jedes Mal.

Danach hatte man 2 neue SD Karten angeschafft.
Bei den neuen SD Karten taucht ein anderer Fehler auf. Beim lesen des 
Bootsectors was im check_fs von fatfs gemacht wird, wird das gelesen was 
im Anhang zu sehen ist. Im Anhang ist auch zu sehen, das Active@ Disk 
Editor auf der selben SD-Karte vorfindet. Was sich stark unterscheidet, 
also muss fatfs irgendwie Müll lesen, wobei dieser Müll immer identisch 
ist. Fatfs liest also jedes Mal den selben Müll von den beiden 
SD-Karten.
Woraufhin der check_fs-Aufruf fehl schlägt, da "ld_word(fs->win + 
BS_55AA) != 0xAA55" in check_fs true ergibt.

Die anderen 2 SD Karten funktionieren allerdings immer noch einwandfrei.


Hat jemand eine Idee? Ich konnte leider noch nicht mit einem Oszi ran, 
wird aber mein nächster Schritt sein.


Viele Grüße,

Julian

[Jim M. (turboj)]

Julian H. schrieb:
> und man musste beim mounten mit dem Finger den 3.3v mit dem
> MISO Pin überbrücken, dann gings.

MISO braucht bei SD Karten einen Pullup (10k) nach 3,3V sonst 
funktioniert die Initialisierung nicht. Im Auto ist mehr EMV Dreck als 
im Büro, der ~50k interne Pullup vom STM reicht dann nicht.


Der Kartenfehler ist eine Karte im "Idle" State (0x01). In diesem 
Zustand hat sie die Initialisierung (noch?) nicht abgeschlossen.

Schau mal nach ob da nicht aus Versehen ein falsches Dummy Byte gesendet 
wird - zum Lesen von Karte nimmt man am Besten den 0xFF Wert.

Oder checke mal die Spannung mit 'nem Oszi. SD Karten dürfen im SPI Mode 
bis zu 100mA ziehen, manche Versorgung hält das nicht durch.

[Julian H. (julianh)]

Was meinst du mit dem 10k und 50k Pullups? Was sind das für Einheiten?

Jim M. schrieb:
> Der Kartenfehler ist eine Karte im "Idle" State (0x01). In diesem
> Zustand hat sie die Initialisierung (noch?) nicht abgeschlossen.

Könnte daher dieser Datenmüll kommen?
Was halt komisch ist, ist, dass es so scheint als würden die ganzen 
send(CMD01), send(CMD08) Sachen von Fatfs funktionieren (Rückgabewerte 
und Antworten von SD sind richtig).
Erst beim auslesen des ersten Sectors der SD, bei welchem dann das 
Offset 510 auf 0xAA55 überprüft wird (was in check_fs passiert), wird 
von fatfs nur Müll von der SD gelesen (der Müll ist im Dump im Anhang 
meiner ersten Nachricht zu sehen).
Bzw. fatfs sollte doch auch warten bis die SD-Karte sich mit "Die 
Initialisierung der SD war erfolgreich!" zurück gemeldet hat bevor fatfs 
den ersten Sector der SD ausliest. Und sollte das dann nicht schon von 
fatfs als Fehler abfangbar sein und schon vorher ein Fehler geschmissen 
werden?

Des weitern werden als Dummybytes überall 0xFF gesendet.


Das mit dem Oszi werde ich am Dienstag im Büro testen, meine neuen 
Schlüsse aus der Sache ziehen und mich wahrscheinlich wieder hier 
melden.


Gruß,

Julian

[Stefan F. (Gast)]

> Was meinst du mit dem 10k und 50k Pullups? Was sind das für Einheiten?

Pullups sind Widerstände, die ein Signal auf High Pegel ziehen. "k" 
bedeutet Kilo, also "mal tausend". Da man Widerstände ihn Ohm misst, 
meint er also wohl vermutlich 10.000Ω und 50.000Ω.

[Julian H. (julianh)]

Jim M. schrieb:
> MISO braucht bei SD Karten einen Pullup (10k) nach 3,3V sonst
> funktioniert die Initialisierung nicht. Im Auto ist mehr EMV Dreck als
> im Büro, der ~50k interne Pullup vom STM reicht dann nicht.

Stefan U. schrieb:
> Pullups sind Widerstände, die ein Signal auf High Pegel ziehen. "k"
> bedeutet Kilo, also "mal tausend". Da man Widerstände ihn Ohm misst,
> meint er also wohl vermutlich 10.000Ω und 50.000Ω.

Ich habe mir das mit den Pullup Netzen etwas genauer angesehen. Ist 
damit von Jim M. also gemeint, dass im Auto der Pullup Widerstand durch 
EMV zu klein wird sodass ein floating Zustand bei geschlossenem Switch 
entsteht könnte und deshalb die Initialisierung nie funktioniert hatte, 
da MISO nicht mehr ausreichen auf GND gezogen wurde? (Wenn man den MISO 
Pin auf HIGH setzt bevor man fatfss f_mount aufruft, funktioniert die 
Initialisierung bei allen SD-Karten. Dies ist auch als Workarround 
eingebaut, den Fehler verstehe ich allerdings nach wie vor nicht.)

Bzw. was passiert denn bei erhöhten EMV Impulsen aus der Umgebung mit 
dem Pullup Netz?



Gruß,

Julian

[Stefan F. (Gast)]

> dass im Auto der Pullup Widerstand durch EMV zu klein wird

Normale Widerstände werden nicht kleiner oder größer.

Der Punkt ist, dass jede Leitung für irgendeine Frequenz als Antenne 
wirkt und dadurch Radiowellen=Störungen empfängt. Indem man die Leitung 
durch einen zusätzlichen Widerstand belastet, reduziert man diesen 
Effekt. Je niedriger der Widerstandswert ist, umso stärker belastet er 
das Signal (und damit auch das Störsignal). Die internen Pull-Up 
Widerstände des µC sind aber recht hochohmig, die stellen für empfangene 
Radiowellen kein nennenswertes Hindernis dar.

Es geht aber auch darum, sicherzustellen, dass die Leitung in den 
ungenutzten Pausenzeiten einen definierten High Pegel haben soll.

[W.S. (Gast)]

Julian H. schrieb:
> Verbindung mit dem Discovery
> Board worauf ein SD-Card Reader über den dafür vorgesehenen
> SPI-Anschluss angeschlossen ist

Huch? Wird auf diesem Board denn nicht der SDIO-Anschluß für die 
SD-Karte benutzt?

Ansonsten erinnere ich mich, daß Chan's FF beim Initialisieren seiner 
inneren Strukturen an irgend einer Stelle schlichtweg voraussetzt, daß 
ein Pointer auf Null steht, was er aber beim Wechsel der SD-Karte nicht 
tut. Deshalb ging ab Kartenwechsel der ganze Datenverkehr mit der Karte 
in die Hose. Also ein oller Bug in FF. Ob der mittlerweile beseitigt 
ist, weiß ich nicht.

W.S.

[Ruediger A. (Firma: keine) (rac)]

Julian H. schrieb:
>
> Die anderen 2 SD Karten funktionieren allerdings immer noch einwandfrei.
>
>

Legt nahe, dass das Problem bei der SD Karte selber liegt. Dort gibt es 
enorme Qualitätsunterschiede. Insbesonders Billigware produziert 
manchmal Ausschuss im zweistelligen Prozentbereich. Wurde aber hier 
schon mehrfach angesprochen.

Bevor Du unnütze Debuggingkapazitäten an Hard- oder Middleware 
verschwendest, solltest Du Kartenprobleme definitiv ausschliessen.

Am Gesten fährst Du mit Industrial Grade SD Karten.

[Julian H. (julianh)]

Ruediger A. schrieb:
> Legt nahe, dass das Problem bei der SD Karte selber liegt.

Das ein Fehler bei den SD Karten vorliegt ist eigentlich auszuschließen. 
Es macht keinen Unterschied von welchem Hersteller, neu oder alt, der 
Fehler tritt total sporadisch auf.


Ich kontte jetzt aber mal mit dem Oszi ran und so wie es aussieht, wird 
der MISO Pin (PB14) beim Senden nicht mal auf 1V hochgezogen.
Wenn man mit dem Finger VDD zu PB14 überbrückt klappt es wieder, danach 
funktioniert dann alles.

Ab dann ist MOSI auf 3.3V und MISO auf 0V, wenn gesendet wird, wird MOSI 
auf 0 gezogen und MISO auf 3.3V.
Passt dann beim Mounten irgendwas mit der Spannung nicht?



Im Anhang noch nen Auszug vom Oszi, wenn der Mountvorgang schief läuft. 
Der MISO-Auschlag am Anfang kommt noch vom Workarround und kann 
irgnoriert werden.


EDIT:
Der Oszi auszug hat mich auf die Idee gebracht, dass gar nicht VDD zu 
MISO überbrückt wird, sondern zufällig auch MOSI auf MSIO. Überbrücke 
ich nun MISO zu MOSI mit nem 1M Ohm Widerstand dann funktioniert das 
Mounten bei jedem Mal. Was läuft da schief?
Das Witzige ist jetzt auch, dass das Mounten ohne überbrücken bei allen 
SD-Karten jedes Mal klappt.
Was nicht gut ist. Es kann jeder Zeit wider passieren da der Fehler noch 
nicht verstanden ist.
Weiß jemand was?

[Jim M. (turboj)]

Julian H. schrieb:
> Ich kontte jetzt aber mal mit dem Oszi ran und so wie es aussieht, wird
> der MISO Pin (PB14) beim Senden nicht mal auf 1V hochgezogen.

Da fehlt die Legende, welche Farbe welches Signal ist.

Wenn gelb CS ist fehlt der Pullup auf MOSI oder hat irgendwas schlechten 
Kontakt (z.B VCC oder GND).

[Julian H. (julianh)]

Jim M. schrieb:
> Da fehlt die Legende, welche Farbe welches Signal ist.

Tut mir Leid. Gelb ist MOSI und grün ist MISO.

Wir haben den selben Fehler auch an verschiedenen Boards.
Weshalb wir uns schon überlegt haben, ob sich die SD vielleicht 
irgendwie statisch auflädt.

[Jim M. (turboj)]

Julian H. schrieb:
> Tut mir Leid. Gelb ist MOSI und grün ist MISO.

Die sagen genau gar nix ohne SCK, und ich sehe oben auch kein Timing.

Ist das relativ langsam und der "Glitch" links ein Antwort-Byte/Bit? 
Oder ist das ein Zeichen für Kontaktprobleme?

Ich sehe da übrigens kein Kommando-Bit Muster auf MOSI.

[Julian H. (julianh)]

Im Anhang ein Bild mit Gelb für SCK und Grün für MISO. Bei MOSI habe ich 
nichts brauchbares zusammen bekommen.

[Stefan F. (Gast)]

Ich habe das Gefühl dass du Misst misst. Oder da ist wirklich ein ganz 
gravierender Hardwaredefekt.

[Julian H. (julianh)]

Hier noch MOSI mit Gelb für SCK und Grün für MOSI.

Stefan U. schrieb:
> Ich habe das Gefühl dass du Misst misst. Oder da ist wirklich ein ganz
> gravierender Hardwaredefekt.

Wieso denkst du, dass ich Misst messe?

EDIT:
Im Anhang noch ein Auszug mit Gelb für SCK und Grün für MOSI wenn das 
Mounten geklappt hat und gerade gesendet wird.

[Julian H. (julianh)]

Für mich sieht es auf den Osziauszügen auf jeden Fall so aus, als würde 
was mit SCK nicht stimmen. Daraufhin habe ich andere SPI Pins 
ausprobiert. Nun sieht die SCK etwas eher so aus wie sie sollte. 
Allerdings tauchen trotzdem weiterhin Mountingfehler auf. Das Oszi zeigt 
auch weiterhin an, dass MOSI bzw. MISO wenn ein Mountingfehler auftaucht 
nicht hochgenug gezogen werden.

Um Hardwarfehler auszuschließen: Es werden an die 5 verschiedene 
STM32F407-Module verwendet, überall der gleiche Fehler.

Kann es sein, dass was mit der Leistungszufuhr nicht stimmt?