FTDI drivers totally crash my PC

[Neverther]

You could always throw livelinux on usb drive and boot it.
Crash -> most likely a hw/interrupt fault.

You shouldn't need to open the comport if it crashes windows just by being plugged in. If you want, every livedisk should come atleast with "screen".

[dannyf]

a) What else could make the PC lock up like that?

That's the process people usually go through ***before*** concluding that the USB driver is faulty.

[miguelvp]

If it's a wiring fault not only could freeze your PC but it might take out one or all of the connected host controllers.

[Fungus]

a) What else could make the PC lock up like that?

That's the process people usually go through ***before*** concluding that the USB driver is faulty.

So...how come it doesn't crash with the other Serial adapter?

Remember: It goes Wifi->Mega->FTDI.

The magical electrical signal that kills the FTDI's USB port would have to come out of the Arduino's serial port (which is clamped to GND/Vcc) without bothering either the Arduino or the Arduino's USB interface. It would then have to go through the FTDI chip's RX/TX pins (which I imagine are also clamped) and do something bad to the FTDI's USB port. All using a 3.3V DC supply.

We can probably discard that possibility.

That leaves radio.

If being too close to a Wifi transmitter can lock up an FTDI chip badly enough to lock up the host PC, the FTDI driver is at fault.

If it's because it creates crazy voltages in the USB wires which are connected to the FTDI chip, it's still a reason to avoid FTDI chips. There's alternatives which don't have this problem.

[free_electron]

Remember: It goes Wifi->Mega->FTDI.

The magical electrical signal that kills the FTDI's USB port would have to come out of the Arduino's serial port (which is clamped to GND/Vcc) without bothering either the Arduino or the Arduino's USB interface. It would then have to go through the FTDI chip's RX/TX pins (which I imagine are also clamped) and do something bad to the FTDI's USB port. All using a 3.3V DC supply.

We can probably discard that possibility.

no we can't

That leaves radio.

If being too close to a Wifi transmitter can lock up an FTDI chip badly enough to lock up the host PC, the FTDI driver is at fault.

no it isn't it is up to the designer of the hardware to see to it that all rules are followed.

if you stick an open ended magnetron right next to your head , power it up and cook your brains you cannot complain the magnetron is defective. The flaw is in your design.

you cannot pull conclusions like that. have you seen the design of the usb-com board ? do they employ proper separation of system and chassis ground ? common mode choke on d+ d- ? proper power supply topology and bypass caps ?


i wouldn't be amazed that this thing is feeding energy into chassis ground as opposed to system ground , lifting the signal levels enough to throw the USB transport out of whack.

this kind of spiderweb constructions are 'not done' for this kind of stuff. especially not wit the wifi around.

[nitro2k01]

Fungus, please perform the steps I suggested in my troubleshooting post, then we can talk.

[wraper]

So did you try the same hardware with uninstalled FTDI driver?

[Fungus]

Let me spell out how to troubleshoot for you:

Is it only the mouse and keyboard that are frozen, or everything? Try for example playing a video and press the reset button and see if the video freezes too.

As I said in a previous post: "Mouse stops moving, video stops playing"

A couple of times the video started to stutter and it took a few seconds to lock up (long after I released the reset button).

Similarly, check that you're not shorting or near shorting +5V to ground when pressing the reset button, for example due to an incorrect pullup, or that the reset pin is connected directly to +5V, either on your board by mistake, or on the wireless transmitter PCB.

Nope. I can hold the button down as long as I like. The Arduino (which is powering the Wifi module) keeps going, no power LEDs go dim.

[Fungus]

Fungus, please perform the steps I suggested in my troubleshooting post, then we can talk.

I've already solved it. I took FTDI out of the equation. Everything has been working fine for two days now.

[exapod]

Why do you need an external usb to uart when there is one on the arduino mega?
How is the reset button connected ?
When you connect the ftdi board you must also connect the ground.
Have you tried powering the mega from a battery and connecting the ftdi to the pc to see if it is a ground problem?

[nitro2k01]

I've already solved it. I took FTDI out of the equation. Everything has been working fine for two days now.

Pft! But I'm curious what actually caused the issue. Aren't you?

[HackedFridgeMagnet]

Pft! But I'm curious what actually caused the issue. Aren't you?

Fungus has shown little interest in getting to the cause of the issue, but he was quick to point the finger.
My feeling is he is just trying to get on to the flame FTDI bandwagon.

@Fungus
Now that you have notified the forum of this problem, and gotten people to read your posts. It is time for you to put some effort in a fix this.
This way the issue will probably be resolved, therefore probably helping others.
If it is found that FTDI is at fault, then at least you can point it out to the world with some evidence of fault finding backing you up.

[miguelvp]

He doesn't need to do a thing, it's just a single data point of no consequence.

Unless he really wants to prove FTDI as the culprit but then he will have to actually follow through the investigation.

[Fungus]

@Fungus
Now that you have notified the forum of this problem, and gotten people to read your posts. It is time for you to put some effort in a fix this.

The most likely cause seems (to me) to be radio.

If I add some shielding and that 'fixes' it, does it let FTDI's drivers off the hook?

I have work to do and a deadline for Monday. Maybe next week I can sit around for a day hard-resetting my PC and hoping the file system doesn't get corrupted. Right now? That doesn't seem like a good idea.

[nitro2k01]

The most likely cause seems (to me) to be radio.

Not necessarily. It might also be some other, unknown, combination on signals present on the RX line. Maybe, for example, pulling the FTDI chip's rx line low, maybe in combination with other factors, causes the driver to hand in an infinite loop. But we don't know without further research. That's the point of my exercise of disconnecting one serial line at a time and see if the problem is eliminated.

If I add some shielding and that 'fixes' it, does it let FTDI's drivers off the hook?

You're missing the point. The point isn't "blaming FTDI" or "letting FTDI off the hook". The point is identifying the exact cirumstances and reason this issue is happening to help people in the future, as well as possibly helping FTDI fix it, if applicable.

[Fungus]

The most likely cause seems (to me) to be radio.

Not necessarily. It might also be some other, unknown, combination on signals present on the RX line. Maybe, for example, pulling the FTDI chip's rx line low, maybe in combination with other factors, causes the driver to hand in an infinite loop. But we don't know without further research. That's the point of my exercise of disconnecting one serial line at a time and see if the problem is eliminated.

What if the radio theory needs some particular combination of wires to be connected?

[ve7xen]

Regardless of the trigger, I think there is a point to be made that the driver should be "intrinsically safe". It's kernel-mode code and should be written well enough that it can't hang or crash the entire system under any foreseeable condition. Interrupt handlers should be guaranteed to finish in a certain amount of time and not depend on external data, etc. The only way I can think of to freeze a modern machine hard is to disable interrupts (usually in an interrupt handler) and then get stuck in a busy-wait or something without re-enabling them. That's poor code. If in fact it is the FTDI driver and not the USB driver or something (which seems less likely), I think they do deserve some of the blame regardless of the jankiness of the setup and adverse conditions created by it.

[zapta]

Data point: In some situations a genuine FTDI crashes, kills host PC. A Mega16U2 doesn't.

Well, there are more data points on Elvis sightings.

Yes, he gave many live shows in front of huge crowd.

[free_electron]

Regardless of the trigger, I think there is a point to be made that the driver should be "intrinsically safe". It's kernel-mode code and should be written well enough that it can't hang or crash the entire system under any foreseeable condition. Interrupt handlers should be guaranteed to finish in a certain amount of time and not depend on external data, etc. The only way I can think of to freeze a modern machine hard is to disable interrupts (usually in an interrupt handler) and then get stuck in a busy-wait or something without re-enabling them. That's poor code. If in fact it is the FTDI driver and not the USB driver or something (which seems less likely), I think they do deserve some of the blame regardless of the jankiness of the setup and adverse conditions created by it.

who says it is the driver that locks up ?  what if the usb host controller on the pc motherboard freezes, causing the HAL to stop functioning. Then it's not FTDi's fault as they operate above the HAL. The HAL died so everything dies. So now you going to blame microsoft ? why not blame the host controller maker that they should have hardware timeouts preventing a bus lock-up. Maybe blame the silicon supplier because the electrons apparently don't run where they should ... Maybe the chip was made with sand from Australia so its electron spin is opposite...   yadda yaddaa yadaaa...

Maybe the boards sits above a layline , or there is too much co(s)mic radiation in that room ...

this is all needless speculation.

point in fact is : a hairball like that with high speed things like USB and RF stuff like wifi is asking for it.

[ve7xen]

who says it is the driver that locks up ?  what if the usb host controller on the pc motherboard freezes, causing the HAL to stop functioning. Then it's not FTDi's fault as they operate above the HAL. The HAL died so everything dies. So now you going to blame microsoft ? why not blame the host controller maker that they should have hardware timeouts preventing a bus lock-up. Maybe blame the silicon supplier because the electrons apparently don't run where they should ... Maybe the chip was made with sand from Australia so its electron spin is opposite...   yadda yaddaa yadaaa...

I did mention this. I think it is much more likely the FTDI drivers, as the Microsoft-supplied USB drivers are much more rigorously coded and well tested. This misbehaviour is quite rare these days, so I'd be inclined to blame the peripheral and its driver than the system.

Anyway make your own judgment on what component is at fault, I just don't think it's unreasonable to expect the system to behave well in adverse conditions.

[Fungus]

who says it is the driver that locks up ?  what if the usb host controller on the pc motherboard freezes, causing the HAL to stop functioning. Then it's not FTDi's fault as they operate above the HAL. The HAL died so everything dies.

I'm pretty sure I won't be able to tell the difference between those two so all the "troubleshooting" hints are a bit pointless.

OTOH I do know that replacing the FTDI adapter with an ATMega16U2 adapter fixed it instantly (and it's not given any trouble since). Everything else in the system remained the same, only the adapter/driver changed.

[Fungus]

point in fact is : a hairball like that with high speed things like USB and RF stuff like wifi is asking for it.

Maybe, but  that's the way most people will be using those modules.

[tggzzz]

OTOH I do know that replacing the FTDI adapter with an ATMega16U2 adapter fixed it instantly (and it's not given any trouble since). Everything else in the system remained the same, only the adapter/driver changed.

Surely all you can deduce from that is that the combination of the FTDI adaptor with everything else in your machine caused the machine to crash.

Which isn't the same as the FTDI adaptor caused the problem.

[exapod]

Where do you bought the ftdi adapter? From the photo it seems a cheap chinese board so i think there is a lot to discuss about the quality of the components and the design of the board (grounding, usb d+ d-, etc) . The other board seems a genuine arduino board.

[HackedFridgeMagnet]

I guess the most obvious things to me are:
reinstall the driver,
also what is the board, and how did you tell it is a real FTDI chip?