SD-Card an NUCLEO Board

martin schrieb:
> Benötigt die SD Card Anbindung am STM32f4 Pull up Widerstände an den
> Datenleitungen oder geht das ohne?

SD kommen hoch als "open drain", brauchen also einen Pullup an MISO und 
an den anderen bei SPI unbenutzten Datenleitungen.

Stefan U. schrieb:
>> SD kommen hoch als "open drain", brauchen also einen Pullup
>
> Die CrumbX1 Boards funktionieren ohne Pull-Up Widerstände. Und glaube
> mit, die habe ich intensiv getestet.

Sich auf die internen Pullups im µC zu verlassen kann auch ins Auge 
gehen. Die haben teilweise recht hohe erlaubte Werte im Datenblatt. Ein 
paar Leckströme oder EMV Störungen und schon hat man den (Daten-)Salat.

SD Karte ohne geschaltete Stromversorgung ist auch doof - die Dinger 
kenne keinen Reset, und ich habe eine Charge auch schon so abschiessen 
können dass man sie komplett vom Strom nehmen musste um sie 
wiederzubeleben.

Das ist ja die Frage die ich oben gestellt habe. WIE ist die SD Card 
verbunden. Direkt oder über ein Breakout? Sind auf dem Breakout bereits 
Pull-Ups drauf? Reichen diese? Sind sie zu stark? Ist ein Pegel Wandler 
mit drauf?

Das eine SD Card immer mit Pull-Up betrieben wird sollte aber definitiv 
klar sein. Denn eine einfache Suche wie "SD Card Pullup" bringt 
Hunderttausende Treffer und alle sprechen von "Ja". Und da spielt es 
keine Rolle ob wie auf dem Nucleo ein STM32 oder ein AVR oder PIC 
werkelt. Das spielt dafür absolut keine Rolle.

Und vorsicht bei CubeMx, sollte das SPI Interrupt gesteuert sein: CubeMx 
startet in seinem Code die Interrupts nicht, das musst du händisch 
selbst machen.

Stefan U. schrieb:
>> Sich auf die internen Pullups im µC zu verlassen kann auch ins
>> Auge gehen.
>
> Die sind beim CrumbX1 NET Board nicht aktiviert.

Dann hättest Du aber arge Probleme bei der Initialisierung. Die Spec auf 
SDcard.org sagt eindeutig dass die Karten als Open Drain hoch kommen bei 
Power-ON.

maritn schrieb:
> Canon    16MB ---- MegaByte ging nicht
> SanDisk 256MB ---- MegaByte ging nicht
> SanDisk  16GB ---- GigaByte ging
>
> Das statistische Pech für diese Woche sollte somit ausgeschöpft sein.

Karten ab 4GB sind SDHC und keine SD. Außerdem verwenden die kleinen 
FAT16 -die 16MB könnte auch FAT12 sein- und nicht FAT32 als Dateisystem. 
Es gibt also reichlich weitere Fehlerquellen.

Stefan U. schrieb:
> ein, es funktiuoniert tadellos. Irgend etwas macht die avrfat32
> Library, dass dort die Pull-Up Widerstände nicht nötig sind.

Eventuell braucht man die bei aktuellen (Micro-)SD Karten auch nicht 
mehr, jedenfalls für die SPI Leitungen.

Der Teil mit dem Open Drain stammt noch aus der MMC Spec - ich dachte 
die wäre in der Beziehung kompatibel.

Dann erscheint aber die 400kHz Beschränkung - die noch immer nach 
Power-On besteht - nur bedingt sinnvoll.

Leider hält sich die öffentlich einsehbare SD Spec hier mit Details 
zurück. Ich würde die Pullups immer noch einbauen - insbesondere wenn 
der große Slot verwendet wird wo auch MMCs rein passen, denn die kommen 
als Open Drain laut MMC Spec hoch.

SPI Mode ist auch nicht sooo empfindlich, denn nach dem ersten 
erfolgreichen CMD0 ist die Karte im SPI Mode und hat denn MISO auf 
Push-Pull gestellt. Wenn der Host die Antwort nicht korrekt empfängt 
sendet er halt noch ein extra CMD0 das keine negativen Auswirkungen hat.

Ich hätte aber Kopfschmerzen - wegen EMV und Stromverbrauch - weil MISO 
in den Pausen dann gar nicht mehr getrieben wird und eventuell als 
Antenne arbeitet - also einen offenen CMOS Input darstellt...