Hi,
ich habe hier einen ATSAMD51G18, welcher per SPI auf zwei Kanälen je 24
Bit Frames empfängt. Diese beiden Kanäle nutzen einen gemeinsamen /SS
und SCK und getrennte Datenleitungen. In den 24-Bit-Daten ist eine
Prüfsumme enthalten. Und an Hand dieser Prüfsumme kann ich feststellen,
dass ca 0,21% aller empfangenen Daten defekt sind.
So initialisiere ich meine beiden SPIs:
Die SERCOMs nutzen beide den GCLK4 (GCLK_PCHCTRL_GEN_GCLK4) welcher auf
90 MHz läuft (das hat nichts mit dem SPI-Clock des externen Masters zu
tun, sondern ist der Clock, mit dem die SERCOMs betrieben werden).
Wechsle ich jetzt zu GCLK2, welcher mit 30 MHz läuft, erhöht sich die
Fehlerrate sogar auf über 50%!
Was könnte denn da schief laufen? Der interne Clock sollte doch vom
Clock der SPI-Leitungen komplett unabhängig sein?
Harstad schrieb:> So initialisiere ich meine beiden SPIs:
Und warum benutzt du nicht die C-Code-Formatierung wie sie bei den
Regeln zum Posten angegeben sind? So muss man deinen Code sehr
mühselig lesen.
Was kommt denn beim SPI-Clock an Frequenz daher?
jo mei schrieb:> Und warum benutzt du nicht die C-Code-Formatierung wie sie bei den> Regeln zum Posten angegeben sind? So muss man deinen Code sehr> mühselig lesen.
Hm? Ich habe ddoch die Code-Tags verwendet?
> Was kommt denn beim SPI-Clock an Frequenz daher?
Der Clock vom SPI-Master liegt aktuell bei 2,4 MHz, andere Master
könnten aber grundsätzlich auch mit anderen Frequenzen daherkommen.
Harstad schrieb:> Ich habe ddoch die Code-Tags verwendet?
Nimm die [c] Tags. So wie in der Beschreibung über jeder Texteingabebox
vorgeschlagen...
Harstad schrieb:> Und an Hand dieser Prüfsumme kann ich feststellen, dass ca 0,21% aller> empfangenen Daten defekt sind.
Das heißt, dieser SPI macht völligen Käse. Für mich geht SPI so, dass
über lange Zeit und auch im erweiterten Profil im Klimaschrank /NULL
FEHLER/ auftreten (im Sinne von "kein einziges falsches, versetztes oder
umgekipptes Bit"). Bestenfalls beim EMV-Burst-Test darf mal ein Bit
umkippen und die Fehlerkorrektur greifen. Denn ein Fehler auf einer SPI
Schnittstelle bedeutet ja auch, dass irgendwo anders auf der
Leiterplatte bei irgendeinem anderen digitalen Signal auch mal ein Bit
kippen könnte. Und das wäre in dieser Häufigkeit ein sofortiger
Vollausfall.
> erhöht sich die Fehlerrate sogar auf über 50%!
Vergiss diese Prozentrechnerei. Der Fehlerzähler muss auf 0 stehen
bleiben, solange du nicht mit dem Viehtreiber an die Leiterplatte gehst.
> Was könnte denn da schief laufen?
Wie sehen deine SPI-Signale auf dem Oszilloskop aus? Passt das Timing
zum Timing im Datenblatt? Verwendest du den richtigen SPI-Modus?
Lothar M. schrieb:> Wie sehen deine SPI-Signale auf dem Oszilloskop aus? Passt das Timing> zum Timing im Datenblatt? Verwendest du den richtigen SPI-Modus?
Auf dem Oszi sieht alles perfekt aus, das Timing passt und die Signale
sind wunderbar rechteckig, noch nicht mal kleine Peaks sind da an den
Flanken zu sehen.
Im Errata-Document des ATSAMD51 ist leider auch nix passendes zu
finden...
> Auf dem Oszi sieht alles perfekt aus, das Timing passt und die Signale
sind wunderbar rechteckig, noch nicht mal kleine Peaks sind da an den
Flanken zu sehen.
Aha. Ganz sicher nicht. Um welchen SPI Baustein geht es ? Du hast
irgendwas falsch verstanden. Es gibt Teile, da muss man jede Zeile des
Datenblattes durchlesen umd den Stolperstein zu finden. Unerwartet muss
eine Flanke vor der Anderen kommen..
Allenfalls Analog Devices ?
Ich geriet schon an Teile, die musste ich im Bitbang Mode ansteuern,
weil eben keiner der SPI Modi passte. Das CS musste weg bovor der Clock
endete
Harstad schrieb:> Auf dem Oszi sieht alles perfekt aus
Zeig doch mal ein Paket ab fallendem SS#... ;-)
> Auf dem Oszi sieht alles perfekt aus
Du hast schon direkt an den Controllerpins gemessen? Bzw: wie lang
sind die Signalleitungen?
Wie sind denn die SPI-Slaves programmiert?
MCs als SPI-Slaves sind fast immer ein Albtraum. Im Prinzip müssen sie
hellsehen können, wann der Master was will. Setzt der Master /SS auf
Low, ist schon alles zu spät.
Das Thema hatten wir doch jetzt schon einige Male, zum Beispiel hier:
Beitrag "SPI-Slave ATSAMD51 / 24 Bit Frames empfangen"
Auf AVR freaks ist das auch schon ein paar Mal aufgetaucht.
Warum immer wieder neue Threads zum gleichen Problem?
Ich sehe ja ein, dass es nervt wenn es immer noch nicht läuft.
Rudolph R. schrieb:> Ich sehe ja ein, dass es nervt wenn es immer noch nicht läuft.
Hmmmmm, wenn man den Titel des Thread liest kommen einem
schon Zweifel über die Wahrnehmungsfähigkeit des TO. Oder
ist es ein Problem mit der Sprache / Ausdrucksfähigkeit?
"SPI empfängt beschädigte Daten": naja, was soll SPI auch anders
machen, es kann ja nicht sagen "ich mag nicht". Es wird also
fressen was daherkommt, ob beschädigt oder nicht.
Lothar M. schrieb:> Zeig doch mal ein Paket ab fallendem SS#... ;-)
Siehe Anhang: einmal ein komplettes Frame, zwei mal ein fast
vollständiges Frame und zwei mal noch Anfang und Ende im Detail.
Die etwas ausgefransten Signale sind meinen angelöteten Leitungen zu
verdanken, wenn ich ohne die mit der Probe direkt auf den entsprechenden
Pin gehe, sieht das besser aus (allerdings kann ich dann auch nur
maximal zwei Signale gleichzeitig darstellen, da mir sonst die Hände
ausgehen).
Stefan ⛄ F. schrieb:> Hier muss der empfangende Mikrocontroller die Daten offenbar bei der> fallenden Flanke an SCK übernehmen. Ist das der Fall?
Ja, das wird mit SERCOM_SPI_CTRLA_CPHA festgelegt.
Stefan ⛄ F. schrieb:> Ist das der Fall?
Siehe den bereits velinkten Beitrag "SPI-Slave ATSAMD51 / 24 Bit Frames empfangen"Rudolph R. schrieb:> Warum immer wieder neue Threads zum gleichen Problem?
Das stimmt allerdings.
Harstad schrieb:> dass ca 0,21% aller empfangenen Daten defekt sind.
Und was ist da "defekt"? Umgekippte Bits? Versetzte Bits?
BTW: hast du es mal mit einer deutlich längeren Pause zwischen den
Telegrammen probiert? Evtl. schafft du das Auslesen nicht rechtzeitig,
weil noch ein Interrupt reinfunkt...
OK, ich habe die Ursache gefunden: es hat absolut nichts mit dem
SERCOM-internen Clock zu tun, den habe ich nur zufällig immer im
gleichen Moment geändert.
Tatsächlich ist es so, dass der Empfang der Daten schief geht, wenn der
SPI-Master bereits sendet und dann erst der ATSAMD51 gestartet wird.
Stelle ich aber sicher, dass der ATSAMD51 bereits läuft, wenn die ersten
Daten vom Master kommen, funktioniert alles komplett problemlos und mit
0% Datenfehlern.
D.h. es sieht so aus, als ob der ATSAMD sich nicht korrekt auf das erste
Frame und dessen /SS aufsynchronisiert und dann irgendwie ins stolpern
kommt. Das dürfte so ja eigentlich auch nicht sein? Oder muss ich so
einen SERCOM-SPI tatsächlich einmal aktiv auf die fallende Flanke von
/SS synchronisieren/starten, damit der mit den empfangenen Daten klar
kommt?
Lothar M. schrieb:> Und was ist da "defekt"? Umgekippte Bits? Versetzte Bits?
Tatsächlich habe ich - wenn das auftritt - zwei Probleme: zufällig
vertauschte Bytes (die dann allerdings bis zum nächsten Reset immer in
identischer Weise vertauscht sind, und deswegen leicht zurückgetauscht
werden konnten) und eben innerhalb der Nutzdaten mit einer Rate von 0,2%
oder >50% umgekippte Bits.
Seit ich aber den Slave immer zuerst starte, habe ich beide Probleme
nicht mehr gesehen.
Harstad schrieb:> Das dürfte so ja eigentlich auch nicht sein?
Solange der MC noch im Reset hängt und noch nicht alle Interfaces
initialisiert sind, wie soll er dann was empfangen?
Harstad schrieb:> Oder muss ich so> einen SERCOM-SPI tatsächlich einmal aktiv auf die fallende Flanke von> /SS synchronisieren
Das ist genau die Aufgabe des /SS-Pins. Sonst könnte man ihn ja
weglassen.
Peter D. schrieb:> Harstad schrieb:>> Oder muss ich so einen SERCOM-SPI tatsächlich einmal aktiv auf die>> fallende Flanke von /SS synchronisieren> Das ist genau die Aufgabe des /SS-Pins.
Aber eigentlich müsste sich der Slave schon von selbst auf den SS#
synchronisieren. Denn dafür ist er ja da. Sprich: es dürfte bestenfalls
der erste Frame korrupt sein.
Harstad schrieb:> zufällig vertauschte Bytes (die dann allerdings bis zum nächsten Reset> immer in identischer Weise vertauscht sind
Dann ist daran nichts "zufällig", sondern völlig "systematisch".
Vermutlich funktioniert die Frame-Synchronisation
Ich würde da zum Test mal deutlich mehr Zeit für den inaktiven SS
lassen. Nicht, dass da einfach nur die 600ns zu kurz sind...
Lothar M. schrieb:> Aber eigentlich müsste sich der Slave schon von selbst auf den SS#> synchronisieren. Denn dafür ist er ja da. Sprich: es dürfte bestenfalls> der erste Frame korrupt sein.
Das hätte ich auch erwartet. Es wäre wirklich schade, wenn dem nicht so
wäre.
Lothar M. schrieb:> Aber eigentlich müsste sich der Slave schon von selbst auf den SS#> synchronisieren.
Das tut er auch. Er weiß damit, daß nun das erste Bit eines Pakets
kommt.
Für die Paketsynchronisation mußt Du aber selber sorgen. Z.B. mit der
High-Flanke des /SS einen Interrupt auslösen, um den Empfangspuffer zu
leeren und das DMA für das neue Paket vorzubereiten.
Läßt Du irgendwelche Leichen im Puffer zurück, können auch nachfolgende
Pakete korrupt sein.
Das /SS = 0 macht nur die Bitsynchronisation und gibt den SCK frei, mehr
nicht.
Peter D. schrieb:> Für die Paketsynchronisation mußt Du aber selber sorgen. Z.B. mit der> High-Flanke des /SS einen Interrupt auslösen, um den Empfangspuffer zu> leeren und das DMA für das neue Paket vorzubereiten.
Ich verwende kein DMA. Ich habe einen Interrupt auf dem RXC-Bit, welches
mir sagt, dass ein Frame komplett empfangen wurde (=/SS geht auf high).
Dann lese ich die empfangenen Daten aus dem DATA-Register aus.
Mit dem RXC-Interrupt werden die Daten vom ATSAMD51 aus dem eigentlichen
Empfangspuffer in das DATA-Register geschoben, so dass dieser sofort
wieder in der Lage ist, mit einer fallenden Flanke an /SS die nächsten
Daten zu empfangen (das behauptet zumindest das Handbuch). Ich hätte
demnach also für die Dauer des nächsten SPI-Frames Zeit, die vorher
angekommenen Daten aus DATA auszulesen ohne dass mir die aktuell
eintrudelnden Bits da irgend was hineinpfuschen könnten.
Wo genau soll ich da noch was synchronisieren? Das sollte doch Aufgabe
der SPI-Hardware sein! Sonst kann ich meine empfangenen Bits ja gleich
von Hand zählen.
Aktuell wird also wohl vermutet, dass der Anfang des Frames nicht
korrekt erkannt wird. Die Bits müssten demnach zwar die richtigen Werte
haben, aber verschoben sein. Kannst du das verifizieren?
Stefan ⛄ F. schrieb:> Aktuell wird also wohl vermutet, dass der Anfang des Frames nicht> korrekt erkannt wird. Die Bits müssten demnach zwar die richtigen Werte> haben, aber verschoben sein. Kannst du das verifizieren?
Nein, das ist eben nicht so. Wenn ich den ATSAMD mitten in einer
laufenden SPI-Übertragung anfangen lasse zu empfangen, habe ich zwei
Effekte:
- Bytes innerhalb eines 24-Bit-Frames sind untereinander vertauscht (das
aber konstant, d.h. beim nächsten Frame sind exakt die gleichen Bytes
vertauscht), hier kommen alle Varianten von Vertauschungen vor; starte
ich alles neu, sind dann andere Bytes vertauscht
- Die Daten sind mit einer Rate von 0,2% .. 60% korrupt, sprich es wird
nicht das empfangen, was gesendet wurde, tatsächlich scheinen dann immer
nur einzelne Bytes eines 24-Bit-Frames betroffen zu sein, im Gegensatz
zu den vertauschten Bytes scheint das aber zufällig zu passieren
Harstad schrieb:> Bytes innerhalb eines 24-Bit-Frames sind untereinander vertauscht
Da würde ich auch sagen, die 600ns Pause sind einfach zu kurz, um in den
Interrupt zu springen und das SPI zu leeren. Sprich, das SPI ist zwar
Bitsynchron, aber bleibt Byteasynchron. Du liest vermutlich immer einen
Mix aus altem und neuen Paket. Sind je Paket immer alle 3 Bytes
unterschiedlich?
Peter D. schrieb:> Da würde ich auch sagen, die 600ns Pause sind einfach zu kurz, um in den> Interrupt zu springen und das SPI zu leeren.
Und wieso funktioniert es dann komplett problemlos und fehlerfrei, wenn
ich dafür sorge, dass der ATSAMD läuft, bevor der Master Daten sendet?
Sorry, aber ich sehe nicht, wie deine Erklärung zu dem Problem passt.
Selbst wenn das die vertauschten (aber nicht zwangsläufig
verschobenen!) Bytes erklärt, erklärt es nicht die komplett gekippten
Bits.
Peter D. schrieb:> Da würde ich auch sagen, die 600ns Pause sind einfach zu kurz, um in den> Interrupt zu springen und das SPI zu leeren.
Mal angesehen davon: ich muss nicht den SPI leeren (weil ich nicht auf
den Empfangsbuffer direkt zugreife), sondern das parallel dazu
vorhandene DATA-Register. Das ist quasi ein FIFO mit zwei Elementen,
also habe ich genau genommen 10 usec Zeit, um mein Daten abzuholen.
Ist ja letztendlich egal, der Slave verpasst anscheinend die erste
Taktflanke.
Wie lang braucht der Prozessor zum aufwachen, und wie lang ist dann die
Mindestzeit zwischen SS und SCK? Das kommt bei dir ja sehr zeitnah
nacheinander.
Oliver
Oliver S. schrieb:> Wie lang braucht der Prozessor zum aufwachen
Der schläft nicht sondern ist immer voll in Betrieb. Wenn keine Daten
eintrudeln und zu verarbeiten sind, schickt der aus dem Mainloop heraus
byteweise Informationen über eine UART-Schnittstelle (die ist noch mal
separat und hat mit dem SPI nichts zu tun, allerdings kann ich daran
erkennen, dass er tatsächlich nicht schläft).
Harstad schrieb:> Der schläft nicht sondern ist immer voll in Betrieb.Harstad schrieb:> Tatsächlich ist es so, dass der Empfang der Daten schief geht, wenn der> SPI-Master bereits sendet und dann erst der ATSAMD51 gestartet wird.
Ok, dann ersetze "schlafen" durch "nicht gestartet sein". Was immer das
dann bedeutet.
Oliver
Oliver S. schrieb:> Ok, dann ersetze "schlafen" durch "nicht gestartet sein". Was immer das> dann bedeutet.
"Starten" heißt, ich schalte das Teil an Spannung, so dass es loslaufen
kann. Das braucht ein paar Millisekunden. Die Zeit ist allerdings egal,
da der MAster ja schon läuft und Daten sendet - der ATSAMD steigt also
an einer beliebigen Stelle im aktuell gesendeten Frame ein.
Noch ein Crosscheck:
- ich starte den ATSAMD
- ich starte meinen SPI-Master
-> die Datenübertragung funktioniert korrekt
- ich stoppe meinen SPI-Master hart, so dass dieser mitten in einem
SPI-Frames unterbrochen wird
- ich starte den SPI-Master wieder
-> die Datenübertragung schlägt wieder fehl, am ATSAMD kommen defekte
Daten an
Es scheint also tatsächlich so zu sein, dass der SERCOM-SPI ins stolpern
kommt, sobald er mitten in einem Frame startet oder ein Frame nicht
korrekt beendet wird.
Harstad schrieb:> ein Frame nicht> korrekt beendet wird.
Normalerweise sollte ein SPI mit der Flanke von /SS den Bitzähler
zurücksetzen und unvollständige Worte verwerfen.
Vielleicht ist die /SS-Leitung unterbrochen oder das SPI so
konfiguriert, daß sie nicht ausgewertet wird. Es gibt auch MCs, wo man
den digitalen Input abschalten kann und er dann konstant low gelesen
wird.
Harstad schrieb:> - ich starte den SPI-Master wieder
Wichtig ist dann aber vor dem Senden eine 1-0 Flanke zu erzeugen, d.h.
den /SS erstmal auf 1 zu setzen.
Harstad schrieb:> - ich stoppe meinen SPI-Master hart, so dass dieser mitten in einem> SPI-Frames unterbrochen wird> - ich starte den SPI-Master wieder> -> die Datenübertragung schlägt wieder fehl, am ATSAMD kommen defekte> Daten an
Was macht den SS in dem Ablauf?
Oliver
Peter D. schrieb:> Normalerweise sollte ein SPI mit der Flanke von /SS den Bitzähler> zurücksetzen und unvollständige Worte verwerfen.
Das wäre das Verhalten, welches ich auch erwartet und als logisch
bezeichnet hätte.
> Vielleicht ist die /SS-Leitung unterbrochen oder das SPI so> konfiguriert, daß sie nicht ausgewertet wird. Es gibt auch MCs, wo man> den digitalen Input abschalten kann und er dann konstant low gelesen> wird.
Ich habe /SS probehalber mal permanent auf high gelassen - dann empfängt
er gar nichts mehr. Ganz ohne /SS geht es also nicht und die Idee, dass
er in einem Modus ist, in dem er nur stupide die Bits zählt, ist damit
auch durch.
Harstad schrieb:> Ich habe /SS probehalber mal permanent auf high gelassen - dann empfängt> er gar nichts mehr. Ganz ohne /SS geht es also nicht und die Idee, dass> er in einem Modus ist, in dem er nur stupide die Bits zählt, ist damit> auch durch.
Ein SPI Slave der permanent nicht(!) selektiert wird, darf nichts
empfangen.
Umgekehrt könnte es interessant werden, wenn /SS permanent low also
aktiv
ist.
Darth Moan schrieb:> Umgekehrt könnte es interessant werden, wenn /SS permanent low also> aktiv ist.
Gleiches Verhalten: es wird nichts emfangen wenn /SS permanent auf low
bleibt.
Harstad schrieb:> Es scheint also tatsächlich so zu sein, dass der SERCOM-SPI ins stolpern> kommt, sobald er mitten in einem Frame startet oder ein Frame nicht> korrekt beendet wird.
Das mag tatsächlich so sein, allerdings klingt das doch eher nach
basteln an Symptomen an statt der Ursache.
Oliver
Peter D. schrieb:> Wichtig ist dann aber vor dem Senden eine 1-0 Flanke zu erzeugen, d.h.> den /SS erstmal auf 1 zu setzen.
Darauf hast Du bisher nicht geantwortet.
Harstad schrieb:> - ich stoppe meinen SPI-Master hart, so dass dieser mitten in einem> SPI-Frames unterbrochen wird> - ich starte den SPI-Master wieder
Wenn Du dazwischen den /SS nicht aktiv auf high setzt, kriegt der Slave
gar nícht mit, daß ein neues Paket anfängt.
CMOS-Eingänge ziehen fast keinen Strom, d.h. die Schaltungskapazität
bleibt noch lange auf low geladen.
Ins Init des Masters gehört daher ein /SS = 1.
Peter D. schrieb:> Darauf hast Du bisher nicht geantwortet.
Ja, der wird ganz zu Anfang auf high gesetzt.
Aber selbst wenn nicht, würde das meine Probleme nicht erklären: ein
korrekt funktionierender SPI würde dann halt den ersten Frame ignorieren
aber den zweiten korrekt empfangen, da dort dann ja mit /SS auf high
angefangen wird (schließlich wurde /SS am Ende des vorangegangenen
Frames ja auf 1 gesetzt).
Peter D. schrieb:> Vielleicht mußt Du in den sauren Apfel beißen und alles über das SPI im> Datenblatt und Usermanual gründlich lesen. Ich selber kenne den Chip> nicht.
Sorry, aber solche Kommentare sind echt nur eins: komplett nutzlos. Wenn
ich das nicht schon gemacht hätte und das Datenblatt eben nicht
weiterhilft, würde ich hier ja wohl nicht fragen! Und ich habe ja auch
explizit nach dem SPI vom ATSAMD51 gefragt und nicht allgemein nach
irgend einem SPI - was dann solche Allgemeinplätze helfen sollen, weißt
vermutlich nicht mal du?
"In 32-bit Extension mode, this bit field configures the data length
after which the flags INTFLAG.RCX or
INTFLAG.DRE are raised "
So wie ich das sehe, geht die Sync NICHT über die steigende Flanke von
SS,
sondern über den Längen-Zähler. So wäre die Byte Verschiebung erklärber.
Ludger
Ludger schrieb:> So wie ich das sehe, geht die Sync NICHT über die steigende Flanke von> SS,
Sync geht IMMER über die steigende Flanke von SS, sonst wäre es kein
SPI. Wenn es zusätzliche Möglichkeiten gibt, ändert das nichts daran.
Und da der TO ja das Datenblatt gründlich gelesen hat, wird er
selbstverständlich die richtigen Flags und Interrupts benutzen.
Oliver
Ludger schrieb:> schade, das wir noch keine Rückmeldung bekommen haben, was denn nun die> Ursache für die Probleme war !
Wenn man nichts mehr hört dann ist es meistens eine beschissene
Verschaltung oder ein beschissener Aufbau. Beides braucht man
ja nicht zeigen sonst würden sich die Leute hier köstlich
amüsieren und herum meckern.
Thread beobachten
Seitenaufteilung abschalten