Forum: Mikrocontroller und Digitale Elektronik SPI empfängt beschädigte Daten bei ATSAMD51


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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:
   // SCK:  PA05
   // /SS:  PA06
   // DATA: PA07
   gpio_set_pin_function(CLKY, PINMUX_PA05D_SERCOM0_PAD1);
   gpio_set_pin_function(SYNCY, PINMUX_PA06D_SERCOM0_PAD2);
   gpio_set_pin_function(Y, PINMUX_PA07D_SERCOM0_PAD3);

   MCLK->APBAMASK.bit.SERCOM0_ = 1;
   GCLK->PCHCTRL[SERCOM0_GCLK_ID_CORE].reg = GCLK_PCHCTRL_GEN_GCLK4 | GCLK_PCHCTRL_CHEN;

   SERCOM0->SPI.CTRLA.bit.ENABLE = 0;
   while(SERCOM0->SPI.SYNCBUSY.bit.ENABLE);
   SERCOM0->SPI.CTRLA.reg = SERCOM_SPI_CTRLA_MODE(2) | SERCOM_SPI_CTRLA_DOPO(0) | SERCOM_SPI_CTRLA_DIPO(3) | SERCOM_SPI_CTRLA_CPHA;
   SERCOM0->SPI.CTRLB.reg = SERCOM_SPI_CTRLB_RXEN;
   SERCOM0->SPI.CTRLC.reg = SERCOM_SPI_CTRLC_DATA32B;
   SERCOM0->SPI.LENGTH.reg = SERCOM_SPI_LENGTH_LENEN | SERCOM_SPI_LENGTH_LEN(3);
   SERCOM0->SPI.CTRLA.bit.ENABLE = 1;
   while(SERCOM0->SPI.SYNCBUSY.bit.ENABLE);

   // SCK:  PA22
   // /SS:  PA20
   // DATA: PA21
   gpio_set_pin_function(CLKX, PINMUX_PA22D_SERCOM5_PAD1);
   gpio_set_pin_function(SYNCX, PINMUX_PA20C_SERCOM5_PAD2);
   gpio_set_pin_function(X, PINMUX_PA21C_SERCOM5_PAD3);

   MCLK->APBDMASK.bit.SERCOM5_ = 1;
   GCLK->PCHCTRL[SERCOM5_GCLK_ID_CORE].reg = GCLK_PCHCTRL_GEN_GCLK4 | GCLK_PCHCTRL_CHEN;

   SERCOM5->SPI.CTRLA.bit.ENABLE = 0;
   while(SERCOM5->SPI.SYNCBUSY.bit.ENABLE);
   SERCOM5->SPI.CTRLA.reg = SERCOM_SPI_CTRLA_MODE(2) | SERCOM_SPI_CTRLA_DOPO(0) | SERCOM_SPI_CTRLA_DIPO(3) | SERCOM_SPI_CTRLA_CPHA;
   SERCOM5->SPI.CTRLB.reg = SERCOM_SPI_CTRLB_RXEN;
   SERCOM5->SPI.CTRLC.reg = SERCOM_SPI_CTRLC_DATA32B;
   SERCOM5->SPI.LENGTH.reg = SERCOM_SPI_LENGTH_LENEN | SERCOM_SPI_LENGTH_LEN(3);
   SERCOM5->SPI.CTRLA.bit.ENABLE = 1;
   while(SERCOM5->SPI.SYNCBUSY.bit.ENABLE);

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?

: Bearbeitet durch Moderator
von jo mei (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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?

: Bearbeitet durch Moderator
von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Joggel E. (jetztnicht)


Bewertung
0 lesenswert
nicht lesenswert
> 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

: Bearbeitet durch User
von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

: Bearbeitet durch Moderator
von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rudolph R. (rudolph)


Bewertung
2 lesenswert
nicht lesenswert
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.

von meiomei (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Harstad (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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).

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Hier muss der empfangende Mikrocontroller die Daten offenbar bei der 
fallenden Flanke an SCK übernehmen. Ist das der Fall?

: Bearbeitet durch User
von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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...

von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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...

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
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?

von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
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

von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
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

von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
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

von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Darth Moan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Oliver S. (oliverso)


Bewertung
1 lesenswert
nicht lesenswert
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

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wird da nicht ein Frame Error gesetzt? Muss man den nicht resetten oder 
so was?

von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Harstad (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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?

von Ludger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
"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

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
von Ludger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
schade, das wir noch keine Rückmeldung bekommen haben, was denn nun die 
Ursache für die Probleme war !


Ludger

von meiomei (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.