FT232R VCC, VCCIO separat

[Alex B. (Firma: Ucore Fotografie www.ucore.de) (alex22)]

Hallo Leute,
leider bin ich auch in die Falle getappt, in die anscheinend schon viele 
getappt sind. Hätte ich mir mal mehr Zeit genommen, das passiert, wenn 
man "schnell mal eben" eine kleine Adapterplatine zeichnet.

Also, FT232RQ. Es soll eine "Adapterplatine" sein, die einerseits via 
USB an einen PC angesteckt wird, andererseits auf eine Baugruppe zu 
Debug-Zwecken eingesteckt wird.

Die Baugruppe hat ihre eigene Spannungsversorgung, 5V.

Ich wollte nun den FT232R über USB versorgen (Pin 1 des USB-Steckers 
an VCC). Ich wollte damit bezwecken, dass ich den FT232 konfigurieren 
kann, auch wenn keine externe Platine angeschlossen ist. Andererseits 
dachte ich, es sei "clever" den VCCIO an die 5V der externen Platine 
anzuschließen. Dies, damit der FT232 nichts auf RX/TX senden kann, wenn 
die externe Platine aus ist (VCCIO = 0V).

Im Datenblatt steht auch überall nur, dass VCC und VCCIO aus der selben 
Quelle stammen "sollen" (should).
Hier auch noch mal: 
https://www.ftdichip.com/Support/Knowledgebase/index.html?canftdidevicesbepoweredin.htm

>Mixing a bus and self powered design is not recommended.

Hier wurde vor zwölf Jahren auch mal darüber diskutiert:
Beitrag "Frage zu FT232"

In den RX/TX-Leitungen habe ich übrigens einen Serienwiderstand (1k).

Aber: ist es denn nun "gefährlich" das IC so zu betreiben? Geht etwas 
kaputt? Oder muss man "nur" auf die richtige Einschalt-/Einsteck 
Reihenfolge achten?

Ich überlege schon, ob ich einen "Hotfix" mit Fädeldraht und ein paar 
Dioden/Widerständen machen muss...

Ich würde mich über Rückmeldungen freuen.

Grüße,
Alex

P.S.: Link zur Herstellerwebseite mit Datenblatt: 
https://ftdichip.com/products/ft232rq/

[Frank K. (fchk)]

Alex B. schrieb:

> Aber: ist es denn nun "gefährlich" das IC so zu betreiben? Geht etwas
> kaputt? Oder muss man "nur" auf die richtige Einschalt-/Einsteck
> Reihenfolge achten?

Ich würde das ganze nicht so betreiben. Der Hersteller hat schon seine 
Gründe, warum er diese Betriebsart nicht empfiehlt. Das ist genau so wie 
bei dem zufällig weichen Ei bei Loriot.

Ich setze übrigens für solche Szenarien gerne 74LVC?T(2)45 Levelshifter 
oder 74LVC2G241 Buffer ein. Da steht dann nämlich im Datenblatt:

"This device is fully specified for partial power-down applications 
using IOFF. The IOFF circuitry disables the output, preventing a 
damaging backflow current through the device when it is powered down."

fchk

[Alex B. (Firma: Ucore Fotografie www.ucore.de) (alex22)]

Schon mal meine eigenen "Lösungsvorschläge", sofern jemand schreibt, 
dass die o.g. Umsetzung nicht betrieben werden kann, sondern eine 
Änderung nötig ist.

Mir fallen zwei Varianten ein:

Variante 1) Ich trenne den 5V-Pin am Stecker zu meiner externen Platine 
ab, sodass meine Platine keine 5V mehr in das VCCIO des FT232 einspeisen 
kann. Stattdessen verbinde ich VCCIO mit VCC, sodass VCCIO dann aus dem 
USB versorgt wird.
Vorteile: einfache Umsetzung.
Nachteile: wenn meine Platine nicht mit Spannung versorgt ist, dann 
findet eine "Phantomspeisung" über TX statt. Gleiches gilt umgekehrt. Da 
ich jeweils 1k in den Leitungen habe, denke ich aber, dass das nicht zu 
Schäden führt.

Variante 2) etwas komplizierter: ich füge eine Diode zwischen VCCIO und 
VCC ein, sodass VCC über VCCIO mit versorgt wird, falls kein USB 
angeschlossen ist. Zusätzlich füge ich eine zweite Diode in die 5V-USB 
ein, die "sperrt", wenn VCC größer ist als die Spannung am USB 
(Rückspeise-Verhinderung). Außerdem füge ich einen Spannungsteiler 
zwischen 5V-USB und RESET ein (Gemäß Datenblatt, Kap. 6.2 Self Powered 
Configuration), sodass das IC in RESET ist, solange kein 5V-USB anliegt.

Was haltet ihr davon?

Viele Grüße,
Alex

[Alex B. (Firma: Ucore Fotografie www.ucore.de) (alex22)]

Frank K. schrieb:
> Ich würde das ganze nicht so betreiben. Der Hersteller hat schon seine
> Gründe, warum er diese Betriebsart nicht empfiehlt. Das ist genau so wie
> bei dem zufällig weichen Ei bei Loriot.

Danke für deine Rückmeldung erstmal!
Also ich würde es so betreiben, sofern ich weiß, dass grundsätzlich 
erstmal nichts dadurch kaputtgehen kann und es, wenn es überhaupt 
Probleme gibt, diese sich nur dadurch äußern, dass keine Kommunikation 
stattfindet, wenn man die einzelnen beteiligten Baugruppen nicht in der 
richtigen Reihenfolge eingesteckt bzw. eingeschaltet hat.

Das das nicht toll ist, ist mir auch klar :-)

Wie beschreiben: der Hersteller schreibt nicht "must not" o.ä.. Ich kann 
im Datenblatt auch keinen Parameter finden, der das verbietet (wenn 
überhaupt, dann bei den "Abs. Max. Ratings" die Einschränkung, dass kein 
Pin > (VCC + 0,5V) sein darf. Das würde ich ja verletzen, wenn an VCC 0V 
sind und an VCCIO schon 5V.

Ich sage mal so: bei der nächsten Revision der Platine werde ich es 
sicherlich anders lösen. Aber die Frage ist ja, ob es zumindest zum 
Testen jetzt erstmal so bleiben kann...

Viele Grüße,
Alex

[Frank K. (fchk)]

Alex B. schrieb:
> Also ich würde es so betreiben, sofern ich weiß, dass grundsätzlich
> erstmal nichts dadurch kaputtgehen kann und es, wenn es überhaupt
> Probleme gibt, diese sich nur dadurch äußern, dass keine Kommunikation
> stattfindet, wenn man die einzelnen beteiligten Baugruppen nicht in der
> richtigen Reihenfolge eingesteckt bzw. eingeschaltet hat.

Genau DAS kann Dir niemand sagen. Das Verhalten ist undefiniert. Es kann 
10 Minuten problemlos funktionieren und dann abbrennen. Der Hersteller 
hat diese Betriebsart nicht vorgesehen und nicht getestet. Es kann sogar 
einzelne Chips geben, bei denen das funktioniert, und andere, bei denen 
das nicht funktioniert. Weißt Du erst hinterher.

fchk

[Alex B. (Firma: Ucore Fotografie www.ucore.de) (alex22)]

Frank K. schrieb:
> Genau DAS kann Dir niemand sagen. Das Verhalten ist undefiniert. Es kann
> 10 Minuten problemlos funktionieren und dann abbrennen. Der Hersteller
> hat diese Betriebsart nicht vorgesehen und nicht getestet.

Abermals danke für deine Rückmeldung. Ich merke schon, eine Diskussion 
mit dir darüber zu führen, was der Hersteller mit "should not" meint, 
ist nicht zielführend.
Vielleicht findet sich ja noch der eine oder die andere, die es im 
realen Betrieb mal gemacht haben und mir über die Resultate berichten 
können.

Abgesehen davon habe ich mal hier in den Anhang die "Original"-Version 
des Schaltplans gehängt (Achtung, fehlerhaft), sowie die zwei oben von 
mir skizzierten "hotfixes".

Dabei noch mal der Hinweis, dass bei Variante 1 die beiden Ausgänge (des 
FT232R und meines Mikrocontrollers) jeweils Treiben können, auch wenn 
der Empfänger nicht versorgt wird. Der Strom wird dabei nur durch die 
1k-Widerstände begrenzt.

Bei Variante 2 denke ich, dass ich alle Vorgaben des FT232R einhalte. 
Ist jedoch etwas umständlicher beim "Hotfix".

@Frank K.: kannst du vielleicht noch mal erklären, wie es mit dem 
74LVC2G241 gehen soll? Ich denke zwar nicht, dass ich den als "Hotfix" 
in diese Platine einbauen würde (zu viel Änderung), aber falls ich die 
Platine noch mal neu bestelle, würde ich den vielleicht bestücken 
lassen. Nur ist mir nicht klar, wie ich ihn anschließen soll. Denn so 
wie ich es sehe, hat der ja nur ein VCC und der eine "enable"-Eingang 
ist auch noch invertiert... Und bei dem 74LVC?T(2)45 sehe ich auch 
nicht, wie mir das hilft, da der anscheinend nur in eine Richtung Daten 
übertragen kann. Ich müsste dann ja schon zwei verbauen... da kann ich 
das schon lieber diskret mit ein paar Transistoren aufbauen, ich glaube 
das kommt kleiner und billiger. Ich habe ja keine MBit/s, sondern nur 
ein paar kbit/s...

Schöne Grüße,
Alex

[Frank K. (fchk)]

Alex B. schrieb:

> Abermals danke für deine Rückmeldung. Ich merke schon, eine Diskussion
> mit dir darüber zu führen, was der Hersteller mit "should not" meint,
> ist nicht zielführend.

Eine Diskussion ist eh nicht zielführend, weil es kein definitives 
Ergebnis geben KANN. Genauso wenig wie bei einer Division durch 0.

> Vielleicht findet sich ja noch der eine oder die andere, die es im
> realen Betrieb mal gemacht haben und mir über die Resultate berichten
> können.

Auch hier wird die Aussagekraft begrenzt bleiben. Weißt Du, in wie 
vielen verschiedenen Fabs das Teil produziert wird oder wie viele 
verschiedene Maskenversionen es gibt?

> @Frank K.: kannst du vielleicht noch mal erklären, wie es mit dem
> 74LVC2G241 gehen soll? Ich denke zwar nicht, dass ich den als "Hotfix"
> in diese Platine einbauen würde (zu viel Änderung), aber falls ich die
> Platine noch mal neu bestelle, würde ich den vielleicht bestücken
> lassen. Nur ist mir nicht klar, wie ich ihn anschließen soll. Denn so
> wie ich es sehe, hat der ja nur ein VCC und der eine "enable"-Eingang
> ist auch noch invertiert...

Du versorgst den Chip ganz normal über den VCC/VCCIO. Der Chip hat im 
Gegensatz zum FTDI-Chip eine Schaltung eingebaut, die verhindert, dass 
der Rest der Schaltung durch ein Logiksignal gespeist wird. Das ist der 
Trick.

> Und bei dem 74LVC?T(2)45 sehe ich auch
> nicht, wie mir das hilft, da der anscheinend nur in eine Richtung Daten
> übertragen kann. Ich müsste dann ja schon zwei verbauen.

Genau so wirds oft auch gemacht. So ein PICKIT3 (der Programmer für PIC 
Mikrocontroller) hat 4 von den Teilen drin.

fchk

[Alex B. (Firma: Ucore Fotografie www.ucore.de) (alex22)]

Frank K. schrieb:
> Genau so wirds oft auch gemacht. So ein PICKIT3 (der Programmer für PIC
> Mikrocontroller) hat 4 von den Teilen drin.

Wenn ich dich richtig verstehe, dann bedeutet das, dass ich zwei 
einkanalige davon verwenden könnte. Das wäre dann der SN74LVC1T45.

Du kannst vielleicht noch mal bestätigen: ich würde dann den ganzen 
FT232R (d.h. sowohl VCC als auch VCCIO) im "bus powered"-Mode betreiben 
(also aus dem USB versorgt) und die TXD/RXD-Signale jeweils durch einen 
SN74LVC1T45, wobei die eine Seite (VCCA) auch vom USB versorgt werden 
würde, die andere Seite von meinem Gerät (VCCB). DIR wäre jeweils so 
konfiguriert, dass die Daten halt in die richtige Richtung 
weitergeleitet werden.

Frank K. schrieb:
> Du versorgst den Chip ganz normal über den VCC/VCCIO. Der Chip hat im
> Gegensatz zum FTDI-Chip eine Schaltung eingebaut, die verhindert, dass
> der Rest der Schaltung durch ein Logiksignal gespeist wird. Das ist der
> Trick.

Hier ist mir leider noch immer nicht klar, wie es gehen soll mit dem 
74LVC2G241. Also, auch hier der ganze FT232R im "bus powered"-Mode. Dann 
den 74LVC2G241 z.B. ebenfalls aus dem USB versorgen. Den "output enable" 
des 74LVC2G241 für das Signal in Richtung meiner Baugruppe von den 5V 
meiner Baugruppe aktivieren lassen. Dann kann der nur Treiben, wenn 
meine BG aktiv ist. OK. Und in die andere Richtung, ja da wäre ja der 
"output enable" von mir aus immer aktiv. Und ja, der "Eingang" ist ja, 
wie ich es verstehe, tolerant gegenüber einem Signal, selbst wenn das IC 
aus ist. D.h. es würde auch klappen. Dann bräuchte ich damit ja sogar 
nur ein IC. Das scheint dann ja eine elegante Lösung zu sein. Nicht für 
den Hotfix, aber für ein eventuelles Redesign. Ich habe es mal 
gezeichnet (Anhang). Ich denke so wird ein Schuh draus...

Kannst du trotzdem mal darüber nachdenken (und kundtun), ob du 
einschätzt, ob es mit den beiden o.g. Hotfixes auch klappt?

Viele Grüße,
Alex

[Frank K. (fchk)]

Alex B. schrieb:

> Wenn ich dich richtig verstehe, dann bedeutet das, dass ich zwei
> einkanalige davon verwenden könnte. Das wäre dann der SN74LVC1T45.

genau.

> Du kannst vielleicht noch mal bestätigen: ich würde dann den ganzen
> FT232R (d.h. sowohl VCC als auch VCCIO) im "bus powered"-Mode betreiben
> (also aus dem USB versorgt) und die TXD/RXD-Signale jeweils durch einen
> SN74LVC1T45, wobei die eine Seite (VCCA) auch vom USB versorgt werden
> würde, die andere Seite von meinem Gerät (VCCB). DIR wäre jeweils so
> konfiguriert, dass die Daten halt in die richtige Richtung
> weitergeleitet werden.

genau. Und DIR bezieht sich immer auf die A-Seite. Die kommt also nach 
inne zum FTDI.

> Frank K. schrieb:
>> Du versorgst den Chip ganz normal über den VCC/VCCIO. Der Chip hat im
>> Gegensatz zum FTDI-Chip eine Schaltung eingebaut, die verhindert, dass
>> der Rest der Schaltung durch ein Logiksignal gespeist wird. Das ist der
>> Trick.
>
> Hier ist mir leider noch immer nicht klar, wie es gehen soll mit dem
> 74LVC2G241. Also, auch hier der ganze FT232R im "bus powered"-Mode. Dann
> den 74LVC2G241 z.B. ebenfalls aus dem USB versorgen. Den "output enable"
> des 74LVC2G241 für das Signal in Richtung meiner Baugruppe von den 5V
> meiner Baugruppe aktivieren lassen. Dann kann der nur Treiben, wenn
> meine BG aktiv ist. OK.
genau. Und Du brauchst einen Pulldown am OE, damit der sicher low ist, 
wenn  die andere Baugruppe aus ist oder nichts dranhängt. Das ist 
übrigens ein Grundsatz - niemals offene Eingänge haben, sondern immer 
mit Pullup oder Pulldown für definierte Verhältnisse sorgen. Manchmal 
sind an den EIngängen schon im Chip selber Pullups oder Pulldowns dran. 
Das steht dann im Datenblatt aber auch ausdrücklich drin, dass man die 
offen lassen darf.

> Und in die andere Richtung, ja da wäre ja der
> "output enable" von mir aus immer aktiv. Und ja, der "Eingang" ist ja,
> wie ich es verstehe, tolerant gegenüber einem Signal, selbst wenn das IC
> aus ist. D.h. es würde auch klappen. Dann bräuchte ich damit ja sogar
> nur ein IC. Das scheint dann ja eine elegante Lösung zu sein. Nicht für
> den Hotfix, aber für ein eventuelles Redesign. Ich habe es mal
> gezeichnet (Anhang). Ich denke so wird ein Schuh draus...

Genau. Es gäbe noch eine dritte Möglichkeit:
https://www.analog.com/en/products/adum1201.html

Damit ist der USB-Adapter gar nicht mehr leitfähig mit dem Controller 
auf der anderen Seite verbunden. Jede Seite hat ihr eigenes VCC, ihr 
eigenes GND und ihre eigenen Datenleitungen. Die beiden Seiten sind 
magnetisch über Spulen miteinander gekoppelt, zwischen denen eine 
Glasschicht als elektrische Isolierung liegt. Glas ist ein extrem guter 
Isolator.
Manchmal braucht man so eine vollständige Trennung, und dafür gibts 
diese Bausteine dann.

> Kannst du trotzdem mal darüber nachdenken (und kundtun), ob du
> einschätzt, ob es mit den beiden o.g. Hotfixes auch klappt?

Variante 1 wird so funktionieren. Variante 2 solltest Du nicht machen, 
weil es da die Möglichkeit gibt, dass VCCIO versorgt wird, aber VCC bzw 
VBUS nicht. Das wäre das gleiche Problem andersrum.

fchk

[Alex B. (Firma: Ucore Fotografie www.ucore.de) (alex22)]

Frank K. schrieb:
> Genau. Es gäbe noch eine dritte Möglichkeit:
> https://www.analog.com/en/products/adum1201.html

Ja klar, die ADUMs sind mir bekannt. Ebenso die Vergleichsprodukte von 
TI etc.. Allerdings aus meiner Sicht hier nicht nötig und preislich 
nicht attraktiv.

Schau mal, ich habe die Skizze mal in einen Schaltplan übersetzt. 
Vielleicht hast du ja Lust den noch mal anzuschauen.

Viele Grüße und Danke für die Tipps/Ideen,
Alex

[Frank K. (fchk)]

Alex B. schrieb:

> Schau mal, ich habe die Skizze mal in einen Schaltplan übersetzt.
> Vielleicht hast du ja Lust den noch mal anzuschauen.

Ja, sollte so passen.

Von wegen "preislich interessant": Schau Dir den MCP2221A an. Der hat 
den Vorteil, dass er keine Treiber braucht. Bis Win 7 will Windows noch 
ein .inf sehen, bei Win 10, Mac und Linux kann man den überall 
reinstecken, und er läuft. Ist dann auch einfacher zu löten.

fchk

[Alex B. (Firma: Ucore Fotografie www.ucore.de) (alex22)]

Frank K. schrieb:
> Von wegen "preislich interessant": Schau Dir den MCP2221A an.

Oh ja, der wäre interessant. Besonders die QFN16-Variante ist mir 4x4mm 
schön klein.

Schau mal, im Anhang noch eine Variante mit zwei SN74LVC1T45.
Ich denke ich werde es so bauen. Dann ist es wirklich auch kompatibel zu 
Zielen, die nicht mit 5V laufen. Ist zwar zurzeit nicht relevant, aber 
kann ja in Zukunft relevant werden...

Schönes Wochenende,
Alex

[Bauform B. (bauformb)]

Alex B. schrieb:
> Ja klar, die ADUMs sind mir bekannt. Ebenso die Vergleichsprodukte von
> TI etc.. Allerdings aus meiner Sicht hier nicht nötig und preislich
> nicht attraktiv.

Gerade bei einem Adapter lohnt sich der Aufwand und bei einem 
Einzelstück ist der Bauteilpreis ja nun garkein Argument. USB ist fast 
immer über den PC geerdet und die übernächste Baugruppe hängt mit ihrem 
GND irgendwo, evt. sogar am Netz... Und für einen Debug-Adapter lohnt es 
doppelt. Den benutzt man, wenn irgendwas spinnt. Da kann ich so einen 
Adapter nicht gebrauchen:

Alex B. schrieb:
> wenn es überhaupt Probleme gibt, diese sich nur dadurch äußern,
> dass keine Kommunikation stattfindet, wenn man die einzelnen
> beteiligten Baugruppen nicht in der richtigen Reihenfolge
> eingesteckt bzw. eingeschaltet hat.

Allerdings finde ich Optokoppler statt ADUM pflegeleichter, ganz 
besonders die ACPL-M61L. Die haben einen normalen CMOS-Ausgang und 
reichen für ein paar MBaud, obwohl sie sehr wenig Strom brauchen.

Der MCP2221 wäre nett, aber er kann nur 8N1. Das mag oft ausreichen, 
aber für einen universellen Adapter ist mir ein FTDI doch lieber. Der 
FT230XS ist genauso klein (na gut, 2 Pins mehr) und eher noch billiger 
als der MCP2221.

[Frank K. (fchk)]

Bauform B. schrieb:

> Der MCP2221 wäre nett, aber er kann nur 8N1. Das mag oft ausreichen,
> aber für einen universellen Adapter ist mir ein FTDI doch lieber. Der
> FT230XS ist genauso klein (na gut, 2 Pins mehr) und eher noch billiger
> als der MCP2221.

Da muss ich echt lange überlegen, wann ich in den letzten 30 Jahren 
überhaupt ein Geräte gehabt hatte, was nicht 8N1 gekonnt hatte. Mir 
fällt echt nichts ein.

Ich finde die MCP2221A deswegen so nett, weil sie CDC-ACM und HID 
machen, und wegen des I2C - das ist auch ganz praktisch. Nur für RS485 
nehme ich noch FTDI. Die Richtungsumschaltung für den Transceiver fehlt 
echt.

fchk

[Alex B. (Firma: Ucore Fotografie www.ucore.de) (alex22)]

Bauform B. schrieb:
> Gerade bei einem Adapter lohnt sich der Aufwand und bei einem
> Einzelstück ist der Bauteilpreis ja nun garkein Argument.

Naja, von Einzelstück war ja nie die Rede... aber eine große Serie ist 
es auch nicht. Ich denke <100 Stück.

Im Anhang wäre dann noch ein Schaltplan für einen galv. getrennten 
mittels ADUM1201. Der könnte dann auch mit einem 3V3-Zielsystem 
arbeiten, aber eben nichts darunter.

Viele Grüße,
Alex