SPI Datenregister Overflow

[Mirco G. (mirco432)]

Hi!

Ich habe das Problem das teilweise meine SPI Kommunikation zu einem 
LTC6813 fehlschlägt. Manchmal geht es und manchmal nicht.

Ich habe jetzt mal mit SWV die Einträge ins Datenregister verfolgt. 
Teilweise wird mir da ein Overflow angezeigt.

Was bedeutet das genau? Bei einer Variable kann ich mir das vorstellen 
aber bei einem Datenregister nicht.

Das ist ja im Endeffekt wie ein Schieberegister. Ich verstehe nicht wie 
ich da einen Overflow haben kann.

Ich verwende einen STM32F4.

Ich verwende zum Senden und Empfangen Funktionen aus der HAL API.

Vielen Dank !

[Beo Bachta (Gast)]

Mirco G. schrieb:
> Das ist ja im Endeffekt wie ein Schieberegister. Ich verstehe nicht wie
> ich da einen Overflow haben kann.

Beim SPI ist der Overflow wohl so zu verstehen dass ein herein-
kommendes Datum nicht aus dem Datenregister gelesen wurde und
vom weiteren Datenstrom überschrieben wurde.

Prinzipiell muss man bei bidirektionalen SPI (der "Normalfall")
beim Schreiben immer auch genau soviel Daten lesen, auch wenn
man sie nicht braucht. Oder das Overflow-Flag ignorieren.

[Viktor B. (coldlogic)]

Ein Overflow beim SPI zeugt davon, dass ein Byte im SPI-Schieberegister 
empfangen, in den Buffer befördert, aber nicht rechtzeitig ausgelesen 
wurde, sodass das zweite empfangene Byte jetzt auf den Platz des ersten 
geschoben werden sollte. Je nach Implementierung in der Hardware 
verliert man zwangsläufig entweder den ersten oder den zweiten Byte. Man 
könnte nachschauen, wie genau Datenregister des SPI ausgelesen wird. 
Wenn per Polling, dann könnte das Intervall etwas zu groß sein. Wenn per 
Interrupt, wird er entweder von einem anderen Interrupt unterbrochen 
(Prioritäten beachten!) oder etwas im Code des Interrupts dauert zu 
lange. Die Taktfrequenz des SPI zu senken könnte auch helfen, allerdings 
nur als Notmaßnahme.

MfG, coldlogic

[Sebastian S. (amateur)]

Irgendwie ist ja SPI ein serielles Protokoll.
Mit dem Takt schubst Du Bit für Bit in einen Puffer. Je nach 
Konstruktion musst Du jetzt jedes empfangene Byte auslesen oder 
weitersenden. Geschieht dies nicht, so kommt es zum Überlauf, wenn vor 
dem Lesen ein weiteres Datum erscheint.
Gibt es einen Automatismus, der die empfangenen Bytes in einen 
Zwischenpuffer übergibt, so kann auch hier ein unterlassenes Holen der 
Daten einen Überlauf bewirken. Selten sind Zwischenpuffer endlos.
Weiterhin kann es sein, dass Du zu großzügig mit den Unterbrechungen 
(bzw. deren verbrauchter Zeit) umgegangen bist. Vielleicht kannst Du ja 
an den Prioritäten herumspielen.
Noch eine Möglichkeit ist, wenn Dein System zu schmutzig ist. Werden 8 
Bit erwartet aber 9 Bit empfangen, so kann das ganze recht lustig enden. 
Ein Relais zur rechten Zeit, kann so etwas recht gut bewirken. Ein FET 
der irgendetwas gewichtiges schaltet auch.

[Darth Moan (Gast)]

Moin,

also diese Overflow Message scheint sich mir eher auf das Trace-System
zu beziehen. Der SWV traced die Datenzugriffe über den SWO Pin wenn
ich das richtig gelesen habe.
Wenn die zu übertragenden Ereignisse zu schnell auftreten, schafft es
das Trace-System nicht mehr, die Information rauszupumpen. Und dann
gibt es einen Overflow (im Trace-System).

Stimmen denn die Daten bis zum Overflow?
Sieht mir nach einem WRCFGA Kommando aus.
Vielleicht musst du eine längere Pause nach einem Transfer machen,
damit die Daten aus dem SWO Pin rausgetickert werden können.

[Mirco G. (mirco432)]

Sry. Das ich erst so spät wieder schreibe. Bin leider unerwartet im 
Krankenhaus gelandet.

Beo Bachta schrieb:
> Beim SPI ist der Overflow wohl so zu verstehen dass ein herein-
> kommendes Datum nicht aus dem Datenregister gelesen wurde und
> vom weiteren Datenstrom überschrieben wurde.

Beo Bachta schrieb:
> Prinzipiell muss man bei bidirektionalen SPI (der "Normalfall")
> beim Schreiben immer auch genau soviel Daten lesen, auch wenn
> man sie nicht braucht. Oder das Overflow-Flag ignorieren.

Viktor B. schrieb:
> Ein Overflow beim SPI zeugt davon, dass ein Byte im SPI-Schieberegister
> empfangen, in den Buffer befördert, aber nicht rechtzeitig ausgelesen
> wurde, sodass das zweite empfangene Byte jetzt auf den Platz des ersten
> geschoben werden sollte. Je nach Implementierung in der Hardware
> verliert man zwangsläufig entweder den ersten oder den zweiten Byte.

Sebastian S. schrieb:
> Irgendwie ist ja SPI ein serielles Protokoll.
> Mit dem Takt schubst Du Bit für Bit in einen Puffer. Je nach
> Konstruktion musst Du jetzt jedes empfangene Byte auslesen oder
> weitersenden. Geschieht dies nicht, so kommt es zum Überlauf, wenn vor
> dem Lesen ein weiteres Datum erscheint.

Ich verstehe was ihr meint. Muss ich die Daten denn wirklich aus dem 
Datenregisters des STM323F4 lesen?

Das lesen ist ja eigentlich nur ein kopieren des Registerswertes in eine 
Variable. Dabei wird das Register ja auch nicht gelöscht.

Ich sende dem IC ja erstmal 2 Byte Befehl und 2 Byte PEC. Was der IC mir 
während der Zeit auswirft ist mir ja komplett egal. Nur nach z.B. den 4 
Bytes für den Befehl "auslesen der Registergruppe A" geschickt habe will 
ich sehen was er mir auf das SPI legt.

Deswegen habe ich zum senden auch wirklich nur immer den 
HAL_SPI_transmit befehl verwendet. Nur wenn ich lesen wollte hab ich 
...._receive verwendet.

Wobei er bei Receive natürlich Dummy-Bytes sendet. Bei Transmit nicht. 
Trd liest er nach den 4 Bytes einmal das Register aus.

Viktor B. schrieb:
> Man
> könnte nachschauen, wie genau Datenregister des SPI ausgelesen wird.
> Wenn per Polling, dann könnte das Intervall etwas zu groß sein. Wenn per
> Interrupt, wird er entweder von einem anderen Interrupt unterbrochen
> (Prioritäten beachten!) oder etwas im Code des Interrupts dauert zu
> lange. Die Taktfrequenz des SPI zu senken könnte auch helfen, allerdings
> nur als Notmaßnahme.

OK. Das muss ich mir dann mal anschauen. Hab ehrlich gesagt keine Ahnung 
wie das bei der HAL_API ist.

Ich vermute aber stark das es über Interrupt läuft. Ansonsten müsste ich 
ja genau die Zeit wissen die für die 8 Bytes jeweils verstreicht. Dann 
würde ja nix funktionieren.

Es gibt nur eine Timeout_Duration bei dem HAL Befehl aber der ist denke 
nur dafür da das er nicht ewig auf den Interrupt wartet.

Ich teste mal die Taktfrequenz auf ganz niedrig zu machen.


Sebastian S. schrieb:
> Selten sind Zwischenpuffer endlos.

Einen zwischenpuffer verwende ich ja gar nicht. Oder meinst du das SPI 
Datenregister?

> Weiterhin kann es sein, dass Du zu großzügig mit den Unterbrechungen
> (bzw. deren verbrauchter Zeit) umgegangen bist. Vielleicht kannst Du ja
> an den Prioritäten herumspielen.

Meinst du die Timeout_Duration? Die ist immer ziemlich großzügig ja. 
Welche Prioritäten meinst du ?

Darth Moan schrieb:
> also diese Overflow Message scheint sich mir eher auf das Trace-System
> zu beziehen. Der SWV traced die Datenzugriffe über den SWO Pin wenn
> ich das richtig gelesen habe.
> Wenn die zu übertragenden Ereignisse zu schnell auftreten, schafft es
> das Trace-System nicht mehr, die Information rauszupumpen. Und dann
> gibt es einen Overflow (im Trace-System).

Ich SWV Einstellung als Bild angehangen. SWO Clock kann ich nur auf 
2000,1000,500,250 usw. kHz einstellen.

SPI läuft jetzt auf einer Baudrate mit 656 kbits. Also ist die SWO 
Leitung mit 2000 kHz doch ausreichend getaktet oder?.

Immer vor den Overflows bekomme ich auch die Nachricht

"Timestamp delayed. Packet delayed. "

Ansonsten bekomme ich überall

"No timestamp received for packet, cycles value guessed. "

Das spricht natürlich stark dafür das mit dem Tracen auch etwas nicht 
stimmt.

Aber es muss auch tatsächlich ein Fehler vorliegen weil ich das Register 
ja schreibe und danach wieder auslese und die Werte passen halt nicht.

Ich bin  mit meinem Latein wirklich am Ende.

[Mirco G. (mirco432)]

Aber ich habe gerade nochmal geschaut was ich vom IC bekomme wenn die 
Daten nicht ins register geschrieben wird. In dem Fall bekomme ich als 
erstes Byte ein 0xda zurück. Der Pec den ich dazu empfange passt aber. 
Also möchte der IC mir das auch senden. => Also muss die Kommunikation 
an sich eigentlich stimmen....

Ich weiß nur nicht warum das 0xda....

[Mirco G. (mirco432)]

Ich hab jetzt mal die Datenrate wieder auf 85 kBits gestellt. Jetzt 
funkioniert alles ... es gibt auch keine Overflows mehr im Trace. Die 
frage ist aber warum ?

Ich habe die maximale Datenrate anhand der SCK Zeit aus dem LTC6813 
Datenblatt genommen.

Da steht min 1µs. für tclk. Das wäre ja eine Datenrate von 1000kBits. 
Ich dachte mit 656 hab ich da nen guten Sicherheitsabstand.

[Darth Moan (Gast)]

Moin,

Mirco G. schrieb:
> Ich SWV Einstellung als Bild angehangen. SWO Clock kann ich nur auf
> 2000,1000,500,250 usw. kHz einstellen.
>
> SPI läuft jetzt auf einer Baudrate mit 656 kbits. Also ist die SWO
> Leitung mit 2000 kHz doch ausreichend getaktet oder?.

Naja, es kommt darauf an, was genau aus dem SWO PIN rauskommen muss.
Der Tracer will ja scheinbar einen Timestamp mitschicken, oder auch 
nicht.
Es muss aber prinzipiell die Information drin sein, was für ein Ereignis
getraced wird (zb write) dann die Adresse und die Daten. Ich habe leider
keine Ahnung wie das serielle Protokoll da genau aussieht, aber es ist
schon einiges an Daten zu übertragen. Und die SPI kann auch ein kleines
FIFO haben (weiss nicht wie das bei dir jetzt ist). Es können also ein
paar Schreibzugriffe sehr schnell hintereinander kommen.

Mirco G. schrieb:
> Ich weiß nur nicht warum das 0xda....

Naja, Das erste Byte in CFGA sind GPIO5..1 + REFON +DTEN +ADCOPT.
0xDA bedeutet GPIO5+4+2+1 sehen logische high Pegel. GPIO 3 ein low.
REFON ist 0 (normal nach startup), DTEN ist 1 -> DTEN PIN sieht ein 
high,
ADCOPT ist 0 (default).
Klingt für mich erstmal nicht unplausibel. Allerdings kenne ich die
Spannungen an den GPIOs auf deinem Board nicht.

Mirco G. schrieb:
> Ich hab jetzt mal die Datenrate wieder auf 85 kBits gestellt. Jetzt
> funkioniert alles ... es gibt auch keine Overflows mehr im Trace. Die
> frage ist aber warum ?

Das klingt für mich so, als ob die Datenmenge, die aus dem SWO Pin
rausgetickert werden muss eben so gross ist, dass das nicht schneller
geht. Wenn zu häufig diese Trace Events kommen, gibt es einen Overflow.
Für das letzte Project hatten wir ein 16 Paralel-Interface mit 270MHz
wenn ich mich recht erinnere. (Nexus2)
Beim Aurix hast du 1-2 serielle Ports zu je 2,5Gbit/s zum Tracen
(Aurora).
Das ist eine andere Leistungsklasse, die aber auch eine ganz andere
Preisklasse mit sich bringt. Wenn man da bei Lauterbach oder iSystem
guckt, legt man erstmal die Ohren an. Wohl dem der einen Kunden hat,
der das bezahlt.