mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik FT232RL hat sporadisch Auszeiten von 40 Sekunden


Autor: KlaRa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe bisher mit sehr gutem Erfolg vier Platinen mit dem FT232RL im 
Laufe der letzten zwei Jahre erstellt und im Dauereinsatz. Bei der 
letzten Platine habe ich beim Testen festgestellt, nach 30 - 120 
Sekunden kommt es zu Wartezuständen von 40 bis 90 Sekunden. Danach kann 
es wieder 30 - 120 Sekunden dauern bis der näste Hänger sich einstellt. 
Bei den anderen Schaltungen konnte ich dies noch nicht beobachten. Als 
Steuerprogramm habe ich VB.NET 2008 unter XP mit aktuellem FTDI 
-Treiber. Das Programm durchläuft alle 500-800 ms eine Schleife. 
Folgende Funktionen werden verwendet.

FT_SetDTR
FT_Purge
FT_Read
FT_Send

Der Hänger tritt am häufigsten beim FT_Purge auf, er wurde auch beim 
FT_SetDTR beobachtet. Bislang wurde er nicht beim FT_Read oder FT_Write 
gesehen.

Hat jemand eine Idee?

Gruss Klaus.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe folgendes Problem festgestellt, wenn ich kontinuierlich Daten 
vom µC zum FT232RL und dann zum PC sende, dann sendet mir der FT232RL 
keine Daten vom PC zum µC. Das Problem tritt auf bei Baudraten >9600

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Thomas (Gast)

>Ich habe folgendes Problem festgestellt, wenn ich kontinuierlich Daten
>vom µC zum FT232RL und dann zum PC sende, dann sendet mir der FT232RL
>keine Daten vom PC zum µC.

Wie hast du das festgestellt? Oszi an den Pin gehängt?

> Das Problem tritt auf bei Baudraten >9600

Ich hoffe du verwendest einen passenden Quarz am uC.

MFg
Falk

Autor: Klaus Ra. (klara)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,
ich sende und empfange mit 2400 Bit/s vom FT232RL zum MSP430F2013. Wie 
gesagt bisher ohne offensichtliche Probleme. MSP430-seitig treten hier 
keine Probleme auf. Erstens habe ich da ein Timeout von 1s programmiert 
und zweitens, mein VB.NET Programm steht bei einem FT_Purge. Der Befehl 
sollte nichts mit der anderen Seite, dem MSP430F2013 zu tun haben.
Die Spannungsversorgung läuft nicht über USB, sondern extern. Beim 
USB-Kontakt wird der FT232RL auch resetet.
Gruss Klaus.

Autor: geb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja,ja, der FT232RL. Ich hatte(hab?)folgende Probleme beim Betrieb über 
virtuelles Comport:

1.)Schirm der USB-Buchse nicht auf GND gelegt, Resultat: beim ein oder 
ausschalten der Schreibtischlampe stand die Übertragung.
Denke, der Chip ist recht empfindlich auf Störungen und blockiert dann.

2.Nachdem obiges behoben war,zeigte sich im Dauertest, daß es in 24h bei 
rund 1GB Daten so 7-8 mal vorkam, daß Daten verlorengingen (waren 
geblockte Daten). Das Problem hab ich bis heut nicht gefunden, 
interessanterweise ist es beim Kunden nie aufgetreten.Ich vermute am 
ehesten ein Windows Problem im Zusammenspiel mit der in Lab-Windows 
geschriebenen Applikation,aber es ist auch nicht ausgeschlossen, daß es 
am FT232 liegt.

Wär interessant, wer noch seltsame Verhaltensweisen dieses Teils kennt.

Grüße Gebhard

Autor: Klaus Ra. (klara)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gebhard,
ich dachte auch schon daran, es könnte am FT232RL selber liegen. Ein 
Fehlercode liefert der FT232RL auch nicht zurück. Ich werde mich erst 
Freitag wieder mit dem Problem beschäftigen können. Dann nehme ich mal 
eine andere Platine und teste somit PC und Treiber.
Gruss Klaus.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk: Anfang dachte ich es sei ein Problem mit der Lib von Peter 
Fleury, später stellte ich fest, dass der FT232RL die Daten nicht 
ausgibt. Siehe auch diesen Thread 
Beitrag "Peter Fleury Uart Lib: Problem mit Rx-Interrupt und getc()"

Ich habe sogar extra den kompatibelsten Quarz mit 18,432MHz ausgesucht. 
;-)

@Geb: Der Schirm liegt bei mir auf Masse/GND.

@Klaus: Ich habe und werde keinen speziellen Quellcode schreiben, der 
explizit den FT232RL ansteuert, bei mir muss das über den virtuellen 
COM-Port funktionieren. Ich habe zum Testen HTerm benutzt.

Autor: Klaus Ra. (klara)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich bin eigentlich nicht so recht weitergekommen.
Die beschriebenen Hänger treten sporadisch wie beschrieben beim

FT_SetDTR
FT_ClrDTR
FT_Purge

auf. Also Funktionen die nicht gerade anspruchvoll sind. Es wird sogar 
ein FT_Error geniert, IO-Error.

Das IC hat den Stempel 0705-A und ist erst seit ein paar Wochen von 
Reichelt gekauft worden. Errata´s wie bei TI bietet FTDI nicht an. Die 
lassen sich nicht in die Karten schauen. Das man jetzt noch Chips aus 
2007, 5.KW, verkauft ist schon etwas verdächtig. Ich hoffe nicht, dass 
Reichelt hier besonders günstige Ladenhüter erstanden hat.

Nachdem ich wirklich alles geprüft habe bleibt eigentlich nur der 
Verdacht das der FT232RL ein Problem hat. Ich trau mich aber noch nicht 
so recht daran den TSSOP 28 auszulöten.

Gruss Klaus.

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.