mikrocontroller.net

Forum: FPGA, VHDL & Co. UART Nullfolge Problem


Autor: sim (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Forum. Ich brauche dringend euren Rat.

Ich habe ein Projekt mit einem Lattice XP2-8 am laufen. Es handelt sich 
um eine Kommunikationsanschaltung zur Verarbeitung eines eigenen 
Protokolls. Das Design ist mitlerweile recht umfangreich und hat viel 
Zeit gekostet.

Um die Bits zu übertragen setzte ich eine UART ein, um genauer zu sein, 
dass kostenlose Reference Design von Lattice (ohne WISHBONE). Nach 
langer und mühsamer Fehlersuche in der Testphase sehe ich nun am dem 
Logic Analyzer, dass die UART ab und zu ein Byte im Datenstrom 
übersieht. Es kommt dann einfach KEIN RxRdy Signal. Das zerstört 
natürlich meinen kompletten Rahmen und macht starke Probleme.

Das Problem tritt nur auf wenn Nullen (als Daten mit korrektem Start- 
und Stopbit) übertragen werden. Aber das darf ja nicht sein. Ich muss 
doch in der Lage sein ein Nullbyte zu übertragen!

Die Baudrate leigt bei 115200 Baud, also nicht sonderlich hoch.

Ich habe noch einen Auszug des Logic Analyzers angehängt auf dem man das 
Problem sieht. In der ersten Zeile sind die Daten zu sehen (SIN) in der 
dritten Zeile das RxRdy Signal der UART. Und siehe da, es fehlt eins!

Hat jemand Rat??

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sim schrieb:
> Die Baudrate leigt bei 115200 Baud, also nicht sonderlich hoch.

Ja, aber hoch genug, damit bei ungünstigen Taktteilern die Frequenzen 
auseinander laufen. Ich bilde mir ein, mal was von 0.5% Abweichung 
gelesen zu haben, um eine sichere Übertragung zu gewährleisten.

Vielleicht guckst Du mal in das Referenzdesign, ob Du dort etwas am 
Teiler ändern kannst.

Duke

P.S.: Alternativ sendest Du ein CRC mit, dann siehst Du ob was fehlt.

Autor: sim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meines Wissens nach kann eine UART 2% Abweichung vom Takt ab. Aber egal, 
ich habe den Takt auf dem Oszi und der passt genau!

Das mit dem CRC ist ja schön und gut, den gibt es sogar schon. Aber ich 
kann doch nicht jedes dritte Frame verwerfen weil die UART nicht 
mitmacht, dass geht zu stark auf Kosten der Laufzeit.

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

Bewertung
0 lesenswert
nicht lesenswert
Hat der UART eine Art Resync mit eingebaut (also so, dass er an einem 
Flankenwechsel neu synchronisiert)?
Offenbar erkennt er das Stop-Bit nicht richtig. Das kann passieren, wenn 
er zu schnell abtastet und nicht mehr synchronisiert...

Was passiert, wenn du einen Wert wie x"80" überträgst?
Auch bei diesem Wert sind dann ziemlich viele '0' hintereinander, bevor 
das Stopbit kommt.

> Die Baudrate leigt bei 115200 Baud, also nicht sonderlich hoch.
Kontrollier hier mal alle entsprechenden Einstellungen und miss die 
daraus resultierende Bitdauer...

> Meines Wissens nach kann eine UART 2% Abweichung vom Takt ab. Aber egal,
> ich habe den Takt auf dem Oszi und der passt genau!
Welchen?
Beim RS232 gibt es immer 2 Teilnehmer.

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann wird es sinnvoll sein sich anzugucken warum die Vorbedingungen für 
das RxRdy Signal nicht erfüllt sind.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal ein Zitat aus einem Atmel-Datenblatt [1, p.159]:
UBRR values which yield an actual baud rate differing
less than 0.5% from the target baud rate, are bold in the
table. Higher error ratings are acceptable, but the Receiver
will have less noise resistance when the error ratings are
high, especially for large serial frames...

Teste die Übertragung trotzdem mal mit einer niedrigeren Baudrate.

Duke

[1]
http://atmel.com/dyn/resources/prod_documents/doc2486.pdf

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

Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Teste die Übertragung trotzdem mal mit einer niedrigeren Baudrate.
Es kommt auf das Abtast-Verfahren an.
Wenn nur 1 Abtastung zur Bitmitte erfolgt, dann ist die Fehlertoleranz 
(bezogen auf die Baudrate) größer, denn dann kann dieser Abtastzeitpunkt 
ja um eine halbe Bitdauer schwanken.
Werden aber z.B. 3 Abtastungen gemacht, ist die Wahrscheinlichkeit 
größer, dass eine davon in das nächste Bit hineinfällt...

Ganz wichtig ist natürlich die Erkennung der fallenden Flanke des 
Startbits. Wenn dort schon Ungenauigkeiten auftreten, geht das auf 
Kosten der Toleranz.

Autor: sim (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die vielen Antworten.

Habe es auch schon mit 9600 Baud probiert, mit gleichem Ergebnis.

Das mit dem Resync weiß ich nicht, da ich den UART bis jetzt als 
BlackBox betrachtet habe. Ich bin ja davon ausgegangen, dass er 
funktioniert.

Auch mit x80 das gleiche Problem (siehe Plot Logic Analyzer).

Ich versteh das nicht.

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>da ich den UART bis jetzt als BlackBox betrachtet habe.

Nun, das reicht offensichtlich nicht mehr hin. Du wirst nicht darum 
herumkommen die Ursache zu untersuchen.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sim schrieb:
> Habe es auch schon mit 9600 Baud probiert, mit gleichem Ergebnis.

Dann hast Du wahrscheinlich kein Problem mit der Baudrate.

Probiere mal den Code von Lothar [1]. Der sollte von der Entity her ganz 
gut passen.

Duke

[1] http://www.lothar-miller.de/s9y/categories/42-RS232

Autor: sim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube ich habe das Problem gelöst.

Wie es aussieht hatte ich den UART zu Unrecht unter Verdacht. Was der 
Logik Analyzer nämlich nicht zeigt, ist dass das Eingangssignal nicht 
perfekt ist. Es lag vermutlich an der endlichen Flankensteilheit meines 
Bustreibers. Jetzt takte ich das Eingangssignal über ein D-FlipFlop rein 
und siehe da, kein Problem mehr!

Danke für eure Ideen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  sim (Gast)

>Logik Analyzer nämlich nicht zeigt, ist dass das Eingangssignal nicht
>perfekt ist. Es lag vermutlich an der endlichen Flankensteilheit meines
>Bustreibers.

Glaub ich nicht.

> Jetzt takte ich das Eingangssignal über ein D-FlipFlop rein
>und siehe da, kein Problem mehr!

Das klingt eher nach unsauberer Taktverarbeitung bzw. nicht 
einsynchronisierten Daten.

MFG
Falk

Autor: sim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Das klingt eher nach unsauberer Taktverarbeitung bzw. nicht
> einsynchronisierten Daten.

Mein Takt kommt aus einer PLL die auf dem FPGA sitzt. Und er hat eine 
abweichung zum geforderten UART Takt von 0,3%.

Das sollte doch eigentlich sauber genug sein.

Autor: sim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Außerdem müsste ich einen unsauberen Takt doch als Jitter auf dem Oszi 
erkennen können. Da steht er aber wie eine eins!

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es kommt dann das Startbit, wenn der Empfänger die Flanke nicht 
auswerten kann, weil er beschäftigt ist.

Empfang mit pooling bzw. Interrupt testen.

Joe

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  sim (Gast)

>Mein Takt kommt aus einer PLL die auf dem FPGA sitzt. Und er hat eine
>abweichung zum geforderten UART Takt von 0,3%.

>Das sollte doch eigentlich sauber genug sein.

Das meine ich nicht, eher Sauerreien ala

Taktung FPGA/CPLD.

MFg
Falk

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

Bewertung
0 lesenswert
nicht lesenswert

Autor: sim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> http://www.lothar-miller.de/s9y/archives/64-State-...

Das hört sich für mich nach einer schlüssigen Erleuterung an. War mir so 
nicht bewusst, klingt aber logisch. Aber was ändert die Tatsache des 
eintaktens über ein FF an den unterschiedlichen Signallaufzeiten?

Danke schon einmal

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

Bewertung
0 lesenswert
nicht lesenswert
sim schrieb:
> Aber was ändert die Tatsache des
> eintaktens über ein FF an den unterschiedlichen Signallaufzeiten?
Nichts.
Aber damit hat jeder Pfad /im FPGA/ garantiert genau 1 Taktzyklus lang 
Zeit. Das Signal am "nächsten" FF kann sich nicht einfach noch kurz vor 
der Taktflanke noch mal ändern.

Autor: sim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Macht Sinn. Danke. Ich werde mir das eintakten dann wohl in Zukunft 
angewöhnen um solche Probleme zu vermeiden!

Danke an alle Helfer!

Autor: sim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine Frage zu dem Thema. Sollte man dann auch SPI Signale 
eintakten? Die ändern sich ja mit Bezug auf einen Takt. Ist es dann 
Sinnvoll die genauso zu behandeln?

Gruß Sim

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

Bewertung
0 lesenswert
nicht lesenswert
sim schrieb:
> Sollte man dann auch SPI Signale eintakten? Die ändern sich ja mit
> Bezug auf einen Takt. Ist es dann Sinnvoll die genauso zu behandeln?
Nicht unbedingt.
Wenn es hier um einen Slave geht, dann können die Daten durchaus mit dem 
(lokalen) SPI-CLK verarbeitet werden. Nur der SS muß einsynchronisiert 
werden, denn der sagt ja, dass die Übertragung fertig ist...

Wenn der SS die Einsynchronisierung hinter sich hat, dann sind 
garantiert auch die Daten im Schieberegister stabil. So in etwa wird es 
bei meinem einfachen SPI-Slavbe gemacht:
http://www.lothar-miller.de/s9y/categories/26-SPI-Slave
Nur ist hier (weil simpler CPLD-IO) der SS auch als Takt ausgeführt. Im 
FPGA würde ich den wie gesagt einsynchronisieren, und evtl. eine 
Flankenauswertung machen:
http://www.lothar-miller.de/s9y/categories/18-Flan...

Autor: sim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber wenn ich in meinem Slave nur das SS eintakte und die Datenleitungen 
nicht, dann erzeuge ich mir doch einen (ungewollten) Versatz zwischen SS 
und Daten, oder?

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

Bewertung
0 lesenswert
nicht lesenswert
sim schrieb:
> dann erzeuge ich mir doch einen (ungewollten) Versatz zwischen SS
> und Daten, oder?
Ja, aber das ist egal, denn es müssen ja nur die empfangenen Daten zum 
Zeitpunkt der internen Verarbeitung stabil sein. Zeichne dir das einfach 
mal auf ein Blatt Papier.

Einen Spezialfall gibt es allerdings: wenn danach sofort eine neue 
SPI-Übertragung startet, kann das Eintakten des SS zu Problemen führen. 
Denn dann wird ja das Empfangsregister u.U. schon wieder beschrieben.

Autor: sim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, dass ist klar. Dann setzte ich das FlipFlop zum eintakten aber nicht 
"zwischen Pin" und SS-Eingang der SPI, sondern "zwischen Pin" und meine 
interne Verarbeitung. Richtig?

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

Bewertung
0 lesenswert
nicht lesenswert
sim schrieb:
> sondern "zwischen Pin" und meine interne Verarbeitung. Richtig?
So ist es richtig.

Autor: sim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank.
Ich muss sagen man muss bei so einem FPGA mehr beachten als ich dachte! 
(-:

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]
  • [vhdl]VHDL-Code[/vhdl]
  • [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.