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??
Angehängte Dateien:
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.
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.
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.
Dann wird es sinnvoll sein sich anzugucken warum die Vorbedingungen für das RxRdy Signal nicht erfüllt sind.
Hier mal ein Zitat aus einem Atmel-Datenblatt [1, p.159]:
1 | UBRR values which yield an actual baud rate differing |
2 | less than 0.5% from the target baud rate, are bold in the |
3 | table. Higher error ratings are acceptable, but the Receiver |
4 | will have less noise resistance when the error ratings are |
5 | 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
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.
Angehängte Dateien:
-
x80.png
36 KB
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.
>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.
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
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.
@ 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
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.
Außerdem müsste ich einen unsauberen Takt doch als Jitter auf dem Oszi erkennen können. Da steht er aber wie eine eins!
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
@ 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
Falk Brunner schrieb: > Das meine ich nicht, eher Sauerreien ala http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html
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
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.
Macht Sinn. Danke. Ich werde mir das eintakten dann wohl in Zukunft angewöhnen um solche Probleme zu vermeiden! Danke an alle Helfer!
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
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-Flankenerkennung
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?
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.
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?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.