SPI Slave RX Byte versetzt

OP #5881144
Hallo zusammen

Ich habe einen STM32 F0. Ich habe eine Vollduplex SPI Kommunikation 
zwischen zwei Boards.

Grundsätzlich funktioniert die Kommunikation über die SPI Schnittstelle. 
Aber nach einigen Minuten betrieb habe ich auf einmal einen Versatz im 
RX Empfangsregister. Einzig und alleine hilft ein Reboot des 
Mikrokontrollers.

Immer wenn das CS HIGH wird durchlaufe ich einmal die Funktion
HAL_SPI_TransmitReceive_IT();

Wenn das CS auf LOW wird löse ich einen
HAL_SPI_Abort_IT() und
HAL_SPI_DeInit(ptrHspi) aus.

Wie kann ich am einfachsten die SPI Schnittstelle reseten?
OP #5881238
A. S. schrieb:
> Thomas I. schrieb:
>> habe ich auf einmal einen Versatz im RX Empfangsregister.
>
> Ein Bit? Ein Byte? Mehrere?
Es verschiebt sich BYTE weise
>
> Thomas I. schrieb:
>> Einzig und alleine hilft ein Reboot des Mikrokontrollers.
>
> Wozu? Was läuft denn und was nicht.
Die neuen Daten starten nicht auf RX Register Pos 0 sondern irgendwo
>
> Thomas I. schrieb:
>> Wie kann ich am einfachsten die SPI Schnittstelle reseten?
> CS
> œ disablen
muss ich testen
Beitrag #5881239 wurde von einem Moderator gelöscht.
Gast #5881254
Thomas I. schrieb:
> Grundsätzlich funktioniert die Kommunikation über die SPI Schnittstelle.
> Aber nach einigen Minuten betrieb habe ich auf einmal einen Versatz im
> RX Empfangsregister.

Dann geht in der Software vermutlich etwas schief. Fehlt ein Byte oder 
hast du eins zu viel? ;-)

> Einzig und alleine hilft ein Reboot des Mikrokontrollers.
Das ist unwahrscheinlich. "Alles neu" hilft natürlich erstmal, aber 
damit korrigierst du nur die Symptome. Du hast das eigentliche Problem 
nur noch nicht verstanden. Also hilft z.B. der Debugger, denn du 
vernünftig auf die Fehlerbedingung ansetzen musst, um zu verfolgen, 
warum da etwas schief geht. Laufen noch höher priorisierte Prozesse, die 
den Prozessor zeitweise länger blockieren?
OP #5881313
Wolfgang schrieb:
> Thomas I. schrieb:
>> Grundsätzlich funktioniert die Kommunikation über die SPI Schnittstelle.
>> Aber nach einigen Minuten betrieb habe ich auf einmal einen Versatz im
>> RX Empfangsregister.
>
> Dann geht in der Software vermutlich etwas schief. Fehlt ein Byte oder
> hast du eins zu viel? ;-)
>
>> Einzig und alleine hilft ein Reboot des Mikrokontrollers.
> Das ist unwahrscheinlich. "Alles neu" hilft natürlich erstmal, aber
> damit korrigierst du nur die Symptome. Du hast das eigentliche Problem
> nur noch nicht verstanden. Also hilft z.B. der Debugger, denn du
> vernünftig auf die Fehlerbedingung ansetzen musst, um zu verfolgen,
> warum da etwas schief geht. Laufen noch höher priorisierte Prozesse, die
> den Prozessor zeitweise länger blockieren?

Die Feststellung ist, dass ich besonders schnell einen Abriss erhalte 
wenn ich mit dem Debuger verbunden bin.
Es läuft schon noch einen Interrupt für die UART Schnittstelle sowie 
zwei Timer.
Ich habe die SPI Kommunikation auf ca. 17 kBit/s heruntergenommen. Ich 
habe schon das Gefühl, dass der Mikrokontroller in gewissen Situationen 
nicht hinterher kommt. Ich habe eine Zykluszeit im Durchschnitt von ca 
1.5ms auf dem Main Loop.
#5881347
SPI-Slave auf nem MC ist immer pain in the ass.
Der SPI-Slave muß im Interrupt mit höchster Priorität laufen, sonst 
gehen Daten verloren.
Sendet der Master direkt nach /CS = low, hat der Slave keine Zeit, Daten 
in das SPI zu schreiben, d.h. das erste Byte vom Slave ist Müll.

Typisch baut man ein SPI-Protokoll so auf, daß der Master erst ein 
Befehlsbyte und dann ein Dummybyte sendet. Während des Dummybytes kann 
dann der Slave den Befehl parsen und gültige Daten in das SPI schreiben. 
D.h. ab dem 3.Byte liegen gültige Daten an.
Falls DMA möglich ist, sollte man DMA verwenden.
OP #5881365
Peter D. schrieb:
> SPI-Slave auf nem MC ist immer pain in the ass.
> Der SPI-Slave muß im Interrupt mit höchster Priorität laufen, sonst
> gehen Daten verloren.
> Sendet der Master direkt nach /CS = low, hat der Slave keine Zeit, Daten
> in das SPI zu schreiben, d.h. das erste Byte vom Slave ist Müll.
>
> Typisch baut man ein SPI-Protokoll so auf, daß der Master erst ein
> Befehlsbyte und dann ein Dummybyte sendet. Während des Dummybytes kann
> dann der Slave den Befehl parsen und gültige Daten in das SPI schreiben.
> D.h. ab dem 3.Byte liegen gültige Daten an.
> Falls DMA möglich ist, sollte man DMA verwenden.

Danke für die Hinweise. Das ganze habe ich mit Interrupt funktionen 
aufgebaut. Der Master beginnt nach ca. 3ms nach CS LOW zu senden. DMA 
sollte auch möglich sein, muss ich mir genauer anschauen.
OP #5881372
Jdhdiebdkx schrieb:
> Thomas I. schrieb:
>> Ich habe eine Zykluszeit im Durchschnitt von ca 1.5ms auf dem
>> Main Loop.
>
> Das heißt deine main wird nur alle 1.5ms durchlaufen?! Falls ja, was
> machst du in der ganzen restlichen Zeit?

Es sind sicherlich mehrere Effekte. Der uP läuft mit 8mHz und bedient 
ziemlich viel Peripherie. Timer Uart, SPI, PWM und der Main Code ist 
schon ca 40kB. Ich kann sicherlich die Taktfrequenz hoch setzen damit 
die themen besser abgearbeitet werden.

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 7 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.