www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik SPI Übertragungsfehler


Autor: Rumkugel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tag miteinander!

Ich habe leider ein paar Probleme mit Fehlern bei der SPI Übertragung.

Ich übertrage 17byte große Pakete per SPI von einem ATmega644p (Master) 
zu einem ST91x (ARM9). Das gesamte Paket wird mit Slave Select gerahmt. 
Damit das möglich wurde (bzgl. ARM), musste ich CPHA auf 1 setzen. Die 
uC sitzen auf kleinen Boards und sind über ein ca. 5cm langes 
Flachbandkabel miteinander verbunden.

Wenn ich nun mit SPI Clock von 625kHz übertrage, werden im Schnitt ca. 7 
bis 9% der Pakete mit fehlerhafter Checksum (8bit) übertragen.

Bei 312.5kHz sind es noch immer 1 bis 3%. Da kommt dann immer noch von 
Zeit zu Zeit ein fehlerhafter Wert mit zufällig korrekter Checksum 
durch.

Meine Fragen sind also:
-Sind das nicht viel zu viele Fehler für solche 
Übertragungsraten/-längen?
-Kann man anhand dieser Angaben schon grobe Schnitzer meinerseits 
erkennen?
-Was kann ich tun, um die Übertragungsqualität zu verbessern?

Gruß

Autor: Ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast kein Oszi zur Hand?
Sind Störquellen in der nähe Motoren etc.?
Wie sind die Kontakte?

Normalerweise sollten bei einem so kurzen Stück 300kHz ohne Störungen 
laufen.

Autor: Bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit 99,9%iger Wahrscheinlichkeit Timingfehler.
Vermutlich wechseln die Daten an der aktiven Clockflanke, d.h. es ist 
reiner Zufall, ob neue oder alte Daten übernommen werden.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Rumkugel (Gast)

>Damit das möglich wurde (bzgl. ARM), musste ich CPHA auf 1 setzen. Die

Sicher?

>uC sitzen auf kleinen Boards und sind über ein ca. 5cm langes
>Flachbandkabel miteinander verbunden.

Klingt kurz, kann aber bei schlechter Masseführung Probleme machen. 
Siehe Wellenwiderstand.

>-Sind das nicht viel zu viele Fehler für solche
>Übertragungsraten/-längen?

ABSOLUT!!! Das solten Fehlerraten DEUTLICH unter 1:1.000.000 drin sein!

>-Kann man anhand dieser Angaben schon grobe Schnitzer meinerseits
>erkennen?

Siehe oben. Möglicherweise ein Masse oder Terminierungsproblem.

>-Was kann ich tun, um die Übertragungsqualität zu verbessern?

Siehe Artikel Wellenwiderstand.

MFG
Falk

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht ist aber auch der falsche SPI-Modus eingestellt (Phase und 
Polatity).

Autor: Rumkugel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke erstmal für die schnellen Antworten.

Ein Oszi habe ich in den nächsten Tagen leider nicht zur Hand.
Motoren sind in der Nähe, (ca. 15cm) laufen aber noch nicht...
Die beiden Boards sind maschinell gefertigt/bestückt und die 
Flachbandkabel werden über angelötete Stiftleisten verbunden.

@Falk Brunner:

>>Damit das möglich wurde (bzgl. ARM), musste ich CPHA auf 1 setzen. Die

>Sicher?

laut Datenblatt STR91xFA ARM9:
>There are two cases depending on the data/clock timing relationship
>(see Figure 69):
>● If CPHA=1 (data latched on 2nd clock edge):
> NSS must be held low during the entire transmission. This implies that
> in single slave applications the NSS pin can be tied to VSS.
>● If CPHA=0 (data latched on 1st clock edge):
> NSS must be held low during byte transmission and pulled high between
> each byte to allow the slave to write to the FIFO register.

habe auch mittlerweile alle Konfigurationen durchprobiert. Wenn CPHA 0 
ist und ich versuche ein ganzes Paket zu verschicken, emfpängt der ARM 
(Slave) nur das erste Byte, also habe ich bei beiden CPHA auf 1.
CPOL bleibt bei beiden auf 0.


>Möglicherweise ein Masse oder Terminierungsproblem.

Was den Wellenwiderstand angeht, so vermute ich das Problem eigentlich 
woanders, schließlich hängt die Fehlerrate ganz offensichtlich mit der 
Übertragungsfrequenz zusammen. (bei 156.25Hz haben noch ca. 1% der 
Pakete eine falsche Checksum)
Andererseits gibt es bisher keine Terminierung und auch keine 
Masseleitung zwischen MISO und MOSI (stattdessen 5V). Da kann ich 
allerdings auch wenig dran ändern.

Gruß

Autor: Rumkugel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Vielleicht ist aber auch der falsche SPI-Modus eingestellt (Phase und
>Polatity).

Ich habe mal versuchshalber CPOL an dem ARM (nur an dem ARM!) umgedreht 
und bemerke zu meinem großen Erstaunen keinen Unterschied.
Die Pakete werden noch immer erkannt (leider noch immer mit ca. 1% 
falscher Checksum, also da keine Veränderung)

Wie kann das denn jetzt sein?
Eigentlich dürfte der doch nun gar nichts mehr erkennen, dachte ich..

Gruß

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

probiere alle 4 Varianten durch, ich hatte auch schon Flashbausteine, 
die wohl etwas andere Interpretationen des SPI-Modes und des Timings 
hatten...

Sollte nicht sein, war aber so und sie waren sogar von Atmel und an 
einem AVR.

Gruß aus Berlin
Michael

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ABSOLUT!!! Da sollten Fehlerraten DEUTLICH unter 1:1.000.000 drin sein!
FULL ACK.
Ich hatte mal Probleme mit unseren Softies. Die sagten, da würden im 
EA-Abbild meines SPI falsche Bits übertragen. Daraufhin habe ich 
Prüfprotokolle eingebaut und habe bei Übertragungsraten von 10MBit/s und 
etlichen tausend laufender Geräte bisher keinen einzigen 
Übertragungsfehler.
Ich würde also sagen: Falk, häng da ruhig mal noch drei Nullen dran, und 
mach 1:1.000.000.000 draus...  ;-)

> Vielleicht ist aber auch der falsche SPI-Modus eingestellt
Das war dann übrigens auch der Grund, warum Übertragunsfehler augetreten 
sind: unsere Softies haben mein Datenblatt nicht richtig gelesen und im 
SPI-Master den falschen Modus konfiguriert...  :-o

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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