Hallo, ich betreibe eine SD-Karte im SPI-Mode erfolgreich an einem STM32F101C8T6. Das funktioniert auch alles einwandfrei, solange nicht während des Lesens oder Schreibens ein Timer-Interrupt dazwischenfunkt und scheinbar die Kommunikation kurzfristig unterbricht, sodass ich teilweise nur noch Schrott-Antworten von der Karte bekomme (2GB Hama SD Karte). Weiss jemand, ob es bestimmte Stellen im Kommunikationsablauf gibt, an denen ich keine kleine Pause in der Kommunikation mit der SD-Karte machen darf, damit die Karte noch mit sinnvollen Daten antwortet? Ich würde ungern während des gesamten Lese- oder Schreibvorgangs alle anderen Interrupts abschalten. Vielen Dank.
>Weiss jemand, ob es bestimmte Stellen im Kommunikationsablauf gibt, an >denen ich keine kleine Pause in der Kommunikation mit der SD-Karte >machen darf, Es ist der Karte egal wie lang die Pausen durch Interrupts sind.
hmm, das hatte ich mir schon so gedacht. Dann verstehe ich nicht, wieso die Karte einwandfrei funktioniert, wenn ich den Timer-Interrupt abschalte, während ich einen Block lese. Ich werde das nochmal genauer analysieren, was in den Pausen passiert. Danke für die Antwort schonmal.
Ich hab das jetzt nochmal getestet, um die Einfluss der Aktionen im Interrupt auszuschließen: Ich habe im Timer3 Interrupt (welcher mit 720Hz) aufgerufen wird, mal nur eine Sinnlos-Schleife von 1 bis 1000 eingebaut, um Zeit zu verbraten. Sobald dieser Interrupt aktiv ist, während die Karte gelesen wird, kommen oft Schrott antworten zurück. Das SD-Karte Lesen passiert im Main-Loop, d.h., es kann jederzeit unterbrochen werden. Scheinbar ist es der Karte doch nicht egal, wann sie während der Kommunikation unterbrochen wird?
Da musst du schon konkreter werden und dein Problem genauer schildern. In diversen STM32F103-Systemen bei mir laufen etliche Interrupts. Die Kommunikation Controller <-> Karte wird dabei nie gestört.
Nur so ein Gedanke: Der MOSI-Ausgang des Controllers bleibt auch während des Lesens auf festem Potential? Nicht das der zeitweise hochohmig ist und in längeren Pausen undefiniertes Potential annimmt!
Ich arbeite zwar nur mit AVR8, aber in den sieben Jahren, in denen ich SDCs per SPI dranhängen habe, konnte ich ein solches Verhalten noch nie beobachten.
Heiko schrieb: > Scheinbar ist es der Karte doch nicht egal, wann > sie während der Kommunikation unterbrochen wird? Wenn es so wäre (was prinzipiell natürlich nicht ausgeschlossen werden kann), dann wäre sie schlicht und einfach kaputt. Ich würde es aber doch für sehr viel wahrscheinlicher halten, dass du in deinem Code einen Bug hast, denn ein sich so wie beschrieben äussernder Defekt einer SD-Karte wäre sehr, sehr aussergewöhnlich. Hmm, Moment... Auch denkbar: Nicht die Karte selber ist kaputt, sondern deine Hardware zu deren Anbindung. Eine Unterbrechung der Taktleitung z.B. könnte durchaus diesen Effekt bewirken.
@ S. Landolt (Gast) >Ich arbeite zwar nur mit AVR8, aber in den sieben Jahren, in denen ich >SDCs per SPI dranhängen habe, konnte ich ein solches Verhalten noch nie >beobachten. Ich schon. Wenn man sich mit dem FIFO des UARTs im SPI-Modus ins Knie schießt! Beitrag "Re: Problem mit Micro-SD-Karte" Möglicherweise hat der OP ein ähnliches Problem. Die SD-Karte an sich arbeites sowohl auf Bytes- als auch Kommandoebene voll synchron und erwartet nur MINDEST-Wartezeiten zwischen bestimmten Befehlen, aber keine Mindest-Reaktionszeiten. Sprich, man kann die Kommunikation beliebig langsam machen.
Falk B. schrieb: > Ich schon. Wenn man sich mit dem FIFO des UARTs im SPI-Modus ins Knie > schießt! Alles nur Vermutungen, da der OP sich zu fein ist hier seinen Quelltext zu posten...
Falk B. schrieb: > Ich schon. Wenn man sich mit dem FIFO des UARTs im SPI-Modus ins Knie > schießt! > > Beitrag "Re: Problem mit Micro-SD-Karte" Tja, mit parallelen Abläufen haben die C-ler irgendwie immer wieder Probleme. Das passt irgendwie nicht in ihre Kontrollstrukturen, die sie sich beim stupiden Polling in main() scheinbar unausrottbar angewöhnt haben...
@ c-hater (Gast) >Tja, mit parallelen Abläufen haben die C-ler irgendwie immer wieder >Probleme. Ja mein lieber Haty, alle doof außer dir!!!
Falk B. schrieb: > Ja mein lieber Haty, alle doof außer dir!!! Nicht alle. Es gibt durchaus auch kompetente C-Programmierer. Das Problem ist eigentlich nur, dass diese leider inzwischen eine verschwindend kleine Minderheit darstellen.
Puuuh, tolle Antworten... An alle, die sich mit der Frage ernsthaft auseinandergesetzt haben, vielen Dank. Ich denke wir können diesen Thread jetzt schließen.
@ Falk Brunner: Danke für den Hinweis. Es gibt tatsächlich einen Zusammenhang zwischen den falsch gelesenen Daten und dem UART.
Heiko schrieb: > Ich habe im Timer3 Interrupt (welcher mit > 720Hz) aufgerufen wird, mal nur eine Sinnlos-Schleife von 1 bis 1000 > eingebaut, um Zeit zu verbraten. Das ist ja kaum Zeit, wenn der Compiler es nicht sogar ganz wegoptimiert. Ich vermute mal, da ist ein Bug in Deiner SPI-Lib, daß irgendeine Reihenfolge nicht eingehalten wird. Es könnte auch sein, Deine Lib enthält knappe Timeouts, die bei der kleinsten Unterbrecheung überschritten werden. Man könnte noch viel mehr spekulieren, da ja niemand Details kennt.
Heiko schrieb: > @ Falk Brunner: Danke für den Hinweis. Es gibt tatsächlich einen > Zusammenhang zwischen den falsch gelesenen Daten und dem UART. Und das hat mit Timer3 Interrupt was zu tun ?
Hmm ein Interrupt wird sich nicht auf die Spi Übertragung an sich auswirken. Da Spi ja Hardwareseitig realisiert ist. Das byte was im Tx Buffer liegt wird ohne Unterbrechung rausgeschoben. Schon mal auf die Spi Flags geschaut? Ewt. Ist deine Spi Routine auch fehlerhaft. Ohne Code wird das etwas schwierig. Mögliche Fehler wären den Rx buffer nicht zu prüfen. Denn wenn der von der isr zurück kehrt ist der rx buffer voll. Wie behebt sich denn das Problem? Muss die Karte wieder im spi Mode gebracht werden?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.