FTDI drivers totally crash my PC

[Fungus]

Let's stick to the facts, here's the setup again:



There's exactly six pieces of wire, no more, no less.

There's two pieces of wire going to the FTDI adapter via the USART of the Arduino.

If it was anything to do with power supply or Arduino it would keep on right on doing it even after I switch the FTDI adapter for the Arduino adapter in the photo. If anybody has a plausible/likely theory as to why it wouldn't ... I'm all ears

Everything in the system is either 5V or 3.3V. It's hard to see how to get a voltage outside that range. Even if we can, Arduinos have clamping diodes on all pins and the FTDI chip probably does too. There's no direct (unclamped) path from the WiFi module to the FTDI adapter so power spikes from the Wifi module probably going to arrive there. You might get something in the GHz range getting past the diodes but not with enough power to do any damage.

What does that leave? What would be the difference between the FTDI adapter and the Arduino adapter?

[Fungus]

Question: Let's say I get home tonight and put the FTDI adapter back in ... except I leave out one/both of the wires between Arduino and FTDI adapter.

If it stops crashing, what does that prove either way?

(Remember: Scientific method puts prediction before experiment, not the other way around)

[sunnyhighway]

Proof might need a bit more than those two data-points.
Those two statements dont even mention the FTDI drivers being loaded.

You got me on that one. I was assuming this.
Maybe the OP can shed a light on this?

[exapod]

In my opinion is a ground problem that with the cheap ftdi board causes the bsod.
Ground loops can cause bsod or crash the pc.
In my opinion you should only have one usb conected to the pc (the ftdi one) then connect the ftdi to the arduino mega with the GROUND wire and uart wires and power the mega with an external supply. If it doens't crash the pc is a ground problem.
It will take max 30 second to try...

[wraper]

This is not FTDI branded device. This is One hung low adapter with a chip calling itself ftdi.

Yep, and this is what you'll cling to, no matter what I do....

You did nothing but empty words

[Monkeh]

No serious attempt to diagnose the problem has been made.

We know there is a problem. We know it occurs with the FTDI board attached to the PC. This is the extent of the knowledge: There is no evidence whether it's a hardware fault in the FTDI chip, a board layout problem, a hardware problem in the host PC, a software issue in the Windows USB stack, one in the FTDI driver..

So, let's stick to the facts: It is not working properly, and the owner has no interest in fixing it.

[Fungus]

No serious attempt to diagnose the problem has been made.

Becuase:
a) I've been busy
b) All the naysayers are convinced it must be that my chip is fake and there's no 100%-positive way of proving it isn't (even though it passes the fake-chip-detector test there's no reason to believe it is).

We know there is a problem. We know it occurs with the FTDI board attached to the PC. This is the extent of the knowledge:

Nope. We also know the problem vanishes if FTDI is removed from the system without changing anything else.

[Fungus]

Proof might need a bit more than those two data-points.
Those two statements dont even mention the FTDI drivers being loaded.

You got me on that one. I was assuming this.
Maybe the OP can shed a light on this?

Yes, of course they were loaded. I was using PUTTY serial terminal to view debugging info via the FTDI adapter.

[Monkeh]

We know there is a problem. We know it occurs with the FTDI board attached to the PC. This is the extent of the knowledge:

Nope. We also know the problem vanishes if FTDI is removed from the system without changing anything else.

My apologies, I missed a single word to clarify the obvious. Clearly I am at fault and FTDI are entirely to blame, there is no other possibility.

[Fungus]

You did nothing but empty words

Unlike everybody else here...

Right, I'm back on it. I've got it all reconnected. Let's hear your diagnostic steps and what they'll prove.

No serious attempt to diagnose the problem has been made.

It was on hold. The clock just started ticking again. Let's hear it.

[Fungus]

We know there is a problem. We know it occurs with the FTDI board attached to the PC. This is the extent of the knowledge:

Nope. We also know the problem vanishes if FTDI is removed from the system without changing anything else.

My apologies, I missed a single word to clarify the obvious. Clearly I am at fault and FTDI are entirely to blame, there is no other possibility.

I'm just clarifying it for everybody here. It's important - it eliminates a lot of possibilities, eg. problem with the Arduino.

[wraper]

I'm just clarifying it for everybody here. It's important - it eliminates a lot of possibilities, eg. problem with the Arduino.

How it eliminates anything? As I understand your arduino is plugged in USB as well. Unless you provide separate power and make normal ground it can be blamed in computer crashing as well. Changing one variable (usb-rs232 adapter) does not mean that FTDI is at fault. BTW your USB driver version on screenshot is old which doesn't kill fake chips. And I have a hint how it is possible that arduino is at fault. For example, because of the buggy firmware, your mcu pin which is connected to tx of the FTDI is configured as an output for some moment. That causes excessive current and crashes ftdi chip or usb hub. Easy to check, just add 300R resistor in series and see what happens.

[wraper]

If you have a problem and if changing one part to different type eliminates it, does not necessarily mean that previous part was at fault. It might mean that second part is just more tolerant to some failure mode and actual problem cause is still there. Have seen that happen too many times to blindly blame something right away.

[Fungus]

BTW your USB driver version on screenshot is old which doesn't kill fake chips.

Why would I install a driver whose only purpose is to kill chips?

And I have a hint how it is possible that arduino is at fault. For example, because of the buggy firmware, your mcu pin which is connected to tx of the FTDI is configured as an output for some moment. That causes excessive current and crashes ftdi chip or usb hub. Easy to check, just add 300R resistor in series and see what happens.

Even better: Connect an oscilloscope to those lines and see for yourself what happens during reset.

Clue: The TX line stays high (yellow line), the RX line shows the text the chip sends on reboot.

[wraper]

Junk, you trigger on CH2. So how do you expect to see a failure on CH1. Just put resistors in series of both lines and check what happens. And those waveforms are very "clean" as I see.
P.S
So you even didn't try to check if your FTDI at least pretends to be genuine but found who to blame right away, nice.

[Fungus]

Junk, you trigger on CH2.

Yep. If I trigger on CH1 it just sits there. No trigger. Nothing to see.

So you even didn't try to check if your FTDI at least pretends to be genuine but found a who to blame right away, nice.

Of course I did. I used the python script that runs on Linux that was posted in the other thread (it does the same as FTDI's "brick-em-all" driver but non-destructively).

[wraper]

Then nothing to be afraid of. If something is not doing good, isn't it the first thing to check different driver versions?

[Fungus]

Then nothing to be afraid of. If something is not doing good, isn't it the first thing to check different driver versions?

Who said anything about being afraid? I'm just waiting for all the experts to tell me what to do...

[wraper]

So let's summarize: you want to do nothing by yourself, don't want to listen to anyone's suggestions and still want to blame FTDI. If you really tried to troubleshoot, then nobody would pretend to be a "smartass".

[Fungus]

So let's summarize: you want to do nothing by yourself

Apparently I'm an idiot.

If you really tried to troubleshoot, then nobody would pretend to be a "smartass".

You mean like connecting up a 'scope instead of putting in a resistor? Should I not have done that? My bad.

[wraper]

I must admit that you have done at least something after 6 pages people asking for that. Although you did not put resistors, here is another hint: Vmin = 4.28V, Vmax = 5.48V,  doesn't that suggest something about quality of your setup?

[Fungus]

here is another hint: Vmin = 4.28V, Vmax = 5.48V,  doesn't that suggest something about quality of your setup?

There's some little spikes of noise but a lot of that could be measurement error. I wasn't too careful about connecting the oscilloscope probes and the Wifi module is only a few cm away. I should probably take another couple of screenshots with/without Wifi.

[janoc]

Guys, this thread is literally pain to read.

@Fungus - stop being defensive and actually do what you are asked to test if you want that people help you to diagnose the problem. You still haven't posted the entire setup - how is that Arduino powered up? Using a second USB cable? A schematic would be really helpful - it is hard to see which wire goes where.

BTW, the polyfuse stuff is nonsense - only the current through the Arduino + your Wifi is flowing through it, so if your FTDI module is drawing too much current, that fuse cannot see that! You could have a dead short on the FTDI module and the fuse wouldn't trigger, because the module isn't powered through it.


@The FTDI chip/module blamers

Of course I did. I used the python script that runs on Linux that was posted in the other thread (it does the same as FTDI's "brick-em-all" driver but non-destructively).

Yes, of course they were loaded. I was using PUTTY serial terminal to view debugging info via the FTDI adapter.

This obviously proves that the module does work and isn't bricked. I have seen that script and if the module was dead, there is no way for it to pass that test. So can we put this particular theory to rest?

Junk, you trigger on CH2. So how do you expect to see a failure on CH1. Just put resistors in series of both lines and check what happens. And those waveforms are very "clean" as I see.
P.S
So you even didn't try to check if your FTDI at least pretends to be genuine but found who to blame right away, nice.

You are too fast to judge here. What are you expecting to see? The CH1 shows data from the PC to the chip where there won't be any (he didn't transmit anything to the chip yet). Yeah, there is a bit of ringing on the signal, bloody big deal - this is 110kbps (or slower) burst ... I guess it is pointless to explain you that this cannot crash a PC, at worst the FTDI adapter would read garbage.

The Vmin/Vmax values are a red herring - the scope is picking up the ringing spikes.

Anyhow, this is pointless to continue troubleshooting like this. The circuit needs to be first cleaned up and tested bit by bit (divide and conquer strategy):

1) Test the FTDI module standalone, with connected RX to TX line (loopback). Are you seeing what you are typing in Putty? (make sure local echo is off - should be off by default). I assume this will work, because it has passed the tests, but it is a good sanity check. It will also make sure that it isn't the driver causing some weird-ass problem.

2) Make sure you have proper ground connections everywhere. That means connecting ground wires from your level converter to the Arduino (Is that pink wire ground? It is hard to see. Man, why not to use black as ground instead as is standard?), connecting a ground wire between the FTDI and the Arduino. This is essential, without that it won't work right.

3) I am quite not understanding the point of having the Arduino in the loop (apart from using the 3.3V power rail). What is the firmware doing? Shuffling data between two UARTs, where one is connected to the FTDI and the other to the Wifi? Why aren't you using the Arduino's regular USB-to-serial instead (eliminating the FTDI?). Or why not to connect the FTDI module directly to the Wifi and using only the power regulators on the Arduino?

3.5) Connect the Arduino & the FTDI together (remove the Wifi module with its level converter). Does this work? If you are using the firmware in the Arduino to copy data between the two UARTs, you should be able to short the TX & RX lines together on the one that is to be connected to the Wifi - loopback test again. Is it working?

4) Connect the Wifi - is it working?

When anything breaks during the testing, you know it could have been only the last thing you have changed that broke the camel's back. Why did it break? Too much current? Short circuit? Measure!

Please, do the above and then report back.

[wraper]

You are too fast to judge here. What are you expecting to see? The CH1 shows data from the PC to the chip where there won't be any (he didn't transmit anything to the chip yet). Yeah, there is a bit of ringing on the signal, bloody big deal - this is 110kbps (or slower) burst ... I guess it is pointless to explain you that this cannot crash a PC, at worst the FTDI adapter would read garbage.

I except to see something strange, like MCU pin connected to FTDI TX temporarily configured as output for example. Because this is not about data rate but the cause why computer hangs. Do not forget that he have computer freeze on arduino reset. Because of such fantastic hardware setup, it might be that FTDI chip have lockup on arduino reset because of the current/voltage spike. As computer hangs, I expect it is not just incorrect data, as if FTDI IC would care about it. IMO this is at least failure of normal operation of FTDI IC, USB hub or another hardware failure causing PC hang in result.

[Fungus]

Guys, this thread is literally pain to read.

@Fungus - stop being defensive and actually do what you are asked to test if you want that people help you to diagnose the problem. You still haven't posted the entire setup - how is that Arduino powered up? Using a second USB cable? A schematic would be really helpful - it is hard to see which wire goes where.

I'll stop being defensive the moment everybody stops calling me a clueless idiot.

As mentioned many, many times, the Arduino is powered through a USB cable from the same PC as the FTDI adapter.

There's six wires. Four to the Wifi (+5V, GND, TX, RX) and two to the FTDI (RX, TX). Not worthy of a schematic.

BTW, the polyfuse stuff is nonsense

Nope. The claim was that I don't know how much current the Wifi adapter uses. I do, I've read the docs, I've measured it to verify it. The whole point of my little adapter board is that the Arduino 3.3V pin doesn't supply enough.

The Wifi board is powered via the Arduno polyfuse so it's entirely relevant.

This obviously proves that the module does work and isn't bricked. I have seen that script and if the module was dead, there is no way for it to pass that test. So can we put this particular theory to rest?

What theory? I don't recall anybody saying the module is bricked.

1) Test the FTDI module standalone, with connected RX to TX line (loopback). Are you seeing what you are typing in Putty? (make sure local echo is off - should be off by default). I assume this will work, because it has passed the tests, but it is a good sanity check. It will also make sure that it isn't the driver causing some weird-ass problem.

You honestly think I'm sitting here using a bricked FTDI module without knowing it?

2) Make sure you have proper ground connections everywhere. That means connecting ground wires from your level converter to the Arduino

As noted many, many times, I've done that, it makes no difference.None.  Zip. Nada. Can we put that one to bed? 

(Is that pink wire ground? It is hard to see. Man, why not to use black as ground instead as is standard?)

Of course not. It's the black wire. The pink on is +5V.

connecting a ground wire between the FTDI and the Arduino. This is essential, without that it won't work right.

There's a very solid ground connection via the USB cables, plenty good enough for RS232.

Why aren't you using the Arduino's regular USB-to-serial instead (eliminating the FTDI?).

Life's too short to sit there re-opening the Arduino's serial terminal every I edit the program.

3.5) Connect the Arduino & the FTDI together (remove the Wifi module with its level converter). Does this work?

Of course it does.

4) Connect the Wifi - is it working?

Duh! 

Summing up your post: I'm an idiot.