Hallo zusammen,
ich versuche nun schon seit 7 Stunden, einen wohl kleinen, aber gemeinen
Fehler zu finden:
Obwohl ich bereits sämtliche Tutorials und Beispiele durchprobiert habe,
konnte ich das SPI (1, 4, 5, 6) auf meinem STM32F429-Discovery nicht
richtig konfigurieren.
Es wird kein Clocksignal ausgegeben und keine Daten gesendet. Zwar
schaltet der MOSI Pin entsprechend dem ersten zu sendendem Bit, dennoch
passiert weiter nichts. Das TX Empty Flag bleibt dauerhaft gesetzt, das
RX Not Empty Flag wird beim Schreiben ins DR-Register kurz gesetzt und
erlischt sofort wieder.
Ich habe folgendes versucht zu machen:
- GPIO Takt aktiviert
- SPI Takt aktiviert
- GPIO Pins konfiguriert
- SPI konfiguriert
- Alternate Function der Pins konfiguriert
- SPI enabled
- Daten gesendet
Trotzdem komme ich einfach auf keine Lösung. Selbst Programmcode, den
ich direkt aus dem Internet kopiere, wie z.B. die SPI-LoLevel-Library
von http://mikrocontroller.bplaced.net/wordpress/?page_id=2751 zeigt
dieses Fehlverhalten. Die Clocks habe ich mit SystemInit() konfiguriert
(Projektdatei von genannter Seite heruntergeladen) und mit
ich würde den Fehler am ehesten bei der Warteroutine vermuten.
Ersetz die mal durch ein kurzes for-delay. Wenn das dann funktioniert
hast du den Fehler eingegrenzt bzw wenn nicht, ausgeschlossen.
Ich habe vor den zwei while-Schleifen schon einen for-Zähler eingebaut.
Wie gesagt, TX Empty ist die ganze Zeit gesetzt, RX not empty wird beim
Schreiben vom Data Register gesetzt, dann sofort wieder gelöscht.
Ich sehe nicht wo du die Chipselect Leitung betätigst. Es steht zwar
// hier Code einfügen und
// ChipSelect-Pin auf LO legen
aber tun musst es noch...
Wenn das gegenüber nicht über den Chipselect ausgewählt wird, fühlt es
sich nicht angesprochen, empfängt nichts und sendet auch nichts zurück.
Somit bleibst du wahrscheinlich hier
// warte bis empfang fertig
while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE) == RESET);
hängen, weil nichts zurück kommt.
Gruss
derKer
Die SPI_I2S_*-Funktionen sind meines Wissens für beide
Konfigurationsmodi gleich. Eine Chip-Select-Leitung brauche ich nicht,
das dürfte ja das SPI nicht berühren.
derKer schrieb:> aber tun musst es noch...> Wenn das gegenüber nicht über den Chipselect ausgewählt wird, fühlt es> sich nicht angesprochen, empfängt nichts und sendet auch nichts zurück.> Somit bleibst du wahrscheinlich hier>> // warte bis empfang fertig> while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE) == RESET);>> hängen, weil nichts zurück kommt.>
nein, tut er nicht
Anmerkung 1. der SPI-LoLevel-Code ist getestet und funktioniert
Anmerkung 2.
das senden per SPI von einem Master aus funktioniert
auch ohne das ein Slave angeschlossen ist
Hinweise :
ich würde mal per Debugger nachsehen wo die CPU nach dem SPI_SEND steht
A. entweder in einer ISR die nicht ausprogramiert ist
(typischerweise die Systick-ISR) oder
B. in einem Error-Handler
C. versuch mal das fertig compilierte HEX-File (von
mikrocontroller.bplaced),
das MUSS laufen...ansonsten liegt es an der Hardware
(was ich mir aber nicht vorstellen kann)
AntVor schrieb:> Die CPU wartet in einer Endlosschleife auf RX not Empty, dieses Bit> bleibt (nach einem kurzen Impuls direkt beim DR schreiben) auf 0.
sehr sonderbar,
ich benutze die Library bei mir auf dem STM32F429-Disco-Board
in vielen Projekten ohne Probleme
klingt wie wenn der Clock der "RCC_APB2Periph_SPI1" nicht aktiviert wäre
versuch mal (wie schon geschrieben) das fertig compilierte HEX-File
das ist getestet und benutzt SPI5 an PF7, PF8, PF9
AntVor schrieb:> Die CPU wartet in einer Endlosschleife auf RX not Empty, dieses Bit> bleibt (nach einem kurzen Impuls direkt beim DR schreiben) auf 0.
das hört sich korrekt an:
RXnotEmpty =false bedeutet wohl der rxFifo ist leer. Worauf soll er dann
noch warten?
Ersetz die Abfrage des Rxnotempty-flags durch die Abfrage des
busy-Flags.
Ohne jetzt Genau deinen Code angeschaut zu haben:
Das BSY flag soll man wirklich nur zum herausfinden des Endes benutzen -
zum Feststellen wann das nächste Byte Geschrieben werden kann ist TXE
besser
@AntVor,
ich habe mit deinen 3 Files gerade ein neues Projekt erstellt
und auf mein STM32F429-Disco programmiert
(CoIDE 1.7.4, GCC 4.7 2012q4)
ohne deine include Files, sondern die von ST
(vom STM32F429 für GPIO, RCC, SPI)
und alles funktioniert wie es soll,
(eine Warning wird angezeigt, weil die Variable "wert" nicht benutzt
wird)
aber die CPU bleibt nicht hängen und sendet das was sie soll.
Gruss Uwe
Grundschüler schrieb:> RXnotEmpty =false bedeutet wohl der rxFifo ist leer. Worauf soll er dann> noch warten?
auf den Empfang von einem Byte !
wenn ein Byte gesendet wurde, wird bei SPI auch automatisch eines
empfangen
Markus H. schrieb:> zum Feststellen wann das nächste Byte Geschrieben werden kann ist TXE> besser
es soll aber kein "zweites" Byte geschrieben werden,
es soll gewartet werden, bis man das SPI-RX Byte auslesen kann
und erst DANACH kann (event.) ein zweites Byte gesendet werden
scheinbar funktioniert ja schon das senden nicht :
AntVor schrieb:> s wird kein Clocksignal ausgegeben und keine Daten gesendet.
dann kann logischerweise auch das empfangen nicht funktionieren
der Grund bleibt mir allerdings schleierhaft
(aber ohne Glaskugel ist da nicht weiter beizukommen)
Gruss Uwe
>der Grund bleibt mir allerdings schleierhaft
Vieleicht denkt er ja das der SPI Clock ständig
anliegt wenn er das SPI Modul aktiviert. Der ist
aber nur da wenn man etwas sendet.
Einfach mal
Hey,
könntest du bitte gesamten Projekt-Ordner hochladen? Es kann gut sein,
dass es an den Includes liegt. Da haben wir einiges angepasst (Das
Projekt-Team).
Wäre dir sehr dankbar!
mfg AntVor
die Version 1.0.1 gibts hier, wenn dein Google nicht funktioniert
http://www.st.com/web/en/catalog/tools/PF259429#
Hinweis :
einen Thread starten mit bitte um Hilfe
(und passendem Quellcode)
und dann nach 14 Posts zu schreiben "ihr" habt was
an den Bibliotheken geändert, ist mal wieder typisch
ich bin drausen
Entschuldigung, mein Kollege hat vorhin Mist erzählt.
Selbstverständlich haben wir NICHTS an den Bibliotheken geändert, das
wäre ja vollkommener Schwachsinn.
Soweit ich das beurteilen kann, haben wir die Originale aus der
ST-Firmware verwendet, ich habe gerade noch mal das Änderungsdatum
kontrolliert.
Wir werden das Projekt im August weiterführen und uns bei Bedarf dann
nochmal melden.
Vielen Dank für alle Antworten bisher!.
