Disapearing pl2303 usb serial adapter on rpi2

[Rodney W. Grimes]

> On Fri, Dec 22, 2017 at 12:02:46AM -0800, Rodney W. Grimes wrote:
> > 
> > 
> > Cmos latchup could exibit that behavior, a next test would be
> > to just remove the gnd pin from the data end next time the
> > connection stops working and see if that clears the fault.
> > 
> Tried it, no effect.

I would need a circuit layout diagram to be certain, but I
suspect that if this device does latch up it is going to
stay latched until all sources of voltage are removed.

> > You could also try removing and replacing the data end one pin
> > at a time and see if the fault clears after any one of these,
> 
> Tried that too, likewise no effect. It seems mandatory to lift
> all three serial-end pins _and_ the usb connector.

Try lifting everything but the data end gnd, that would be
the USB connector, and RX and TX.

> > I am suspecting a latch condition in the FTDI TX pin output
>                                            ^^^^ did you mean Prolific?
> The two FTDI usb-serial adapters I have work perfectly.

Ok, me bad, I should try to find a datasheet on the
Prolific and see what its ESD/latchup protection
rathings are.  The FTDI is pretty well protected.

> 
> > buffer caused by out of range voltage caused most likely
> > by excess cable/capacitance induced ringing.
> > 
> The cables are about three feet long, as furnished by the manufacturer.
> I do wonder if slowing the serial speed down might help; a console
> certainly needn't run at 115200 bps.

Maybe, but probably not going to have an effect, but always worth
a try.

> It might help if I indicate the layout of the system, since I gather it's
> perahps a little unusual. There are four hosts, call them com, net,
> ns1 and ns2. They're all networked to a hub, with the usb/serial cables
> arranged so that each RPI2 provides terminal service to the next host
> in the ring:
> 
> com-usb/serial-ns1-usb/serial/-ns2-usb/serial-net-usb/serial-com

Ok, that is good additional data.

> There was a faint tendency for hosts net and ns1 to have more usb/serial
> adapter lockups, so those hosts got FTDI adapters and all was well until
> the host called com (the test box) was upgraded to r326951. Serial link
> uptimes went from weeks or months to hours, for that host only.
> 
> The serial cables obviously ground all four RPI2s together, I think the
> ethernet likewise distributes ground. Wall warts are connected to a single
> outlet strip, are isolated and do not distribute ground. All the cables are 
> confined to a small shelf about one by two feet in size.

I think you are correct in that the serial cables are tying all 4 systems
grounds togeather, I am unclear on what the USB ground isolation rules
are, I would actually suspect they are isolated.  I put an ohm meter on
my ftdi USB serial adapter and its gnd pin is infact tied to the shell
of the USB connector, so that is a ground path.

Ethernet does NOT have any ground wires, they are differential pairs
and isolated via the transceiver.

My pedantic side does not like this stringy "using a signal cable"
as a system ground.  I would rather see all 4 RPI's tied with a
good ground to each other, and disconnect the serial cable gnd
wire.  

> It wouldn't be surprising if this turned out to be a wiring issue, but
> proof has so far proved elusive. Just for completeness, there's a photo
> of the setup at 
> http://www.zefox.net/~fbsd/com_net_ns1_ns2
> Left to right, the hosts are com, net, ns1 and ns2. I admit it isn't 
> pretty, but is far from the biggest cable nightmare seen elsewhere.

Looks okay, but this is still a poor system ground in my mind.  This
is not an earth ground, but a signal ground, and those are usually
best done in a star topology, not a string.

> There is one device not shown, a networked printer sitting on the
> table above the shelf, plugged into the same outlet strip that powers 
> everything in the photo. It has a three-wire cord and probably provides
> a single point ground for the whole network. In principle that should
> be good. Multiple paths to ground are understood to be bad in general 
> and have been mostly avoided.

There is no ground signal path in your ethernet cables, so you do
not haved a "ground loop" that I can see.

> Apologies for the length, thanks for reading!
> 
> bob prohaska
> 
> 

-- 
Rod Grimes                                                 rgrimes at freebsd.org