FTDI drivers totally crash my PC

[Fungus]

I'm just working with one of those new ESP8266 Wifi modules. I've got it connected to an Arduino Mega along with an FTDI USB-to-serial adapter (which checks out as "Genuine FTDI") for debug output.

The module is on a little adapter I made with a 3.3V regulator, reset button and level shifting (it's all 3.3V).

Here's a picture of the setup:



Anyway, the problem: When I hit the reset button on the Wifi module my adapter my PC completely locks up. I have to hit the reset button to get it back again. If I use the official Arduino USB-to-Serial adapter (Mega16U2 based, see picture) then there's no problem at all. I can reset all day long.

I have no idea why it crashes. The FTDI adapter isn't connected directly to the Wifi module, it goes via the Arduino Mega. Is it a burst of radio waves from the Wifi Module trashing the FTDI chip? I dunno but all the Arduino stuff survives just fine. Even is it was that, there's no reason to lock up the PC.

FTDI's whining about their "quality" drivers that everybody else is 'stealing' from them? Pull the other one, it's got bells on it!

Yet another reason for me to not buy any more FTDI product.

[TheRevva]

While I don't intend ever using an FTDI chip again, I'd suggest you look again at your own pic...
To my untrained eyes, you have several BEAUTIFUL antennae in that pic and, in combination with a bit of 'ground shift' due to cable resistance, could possibly even result in some SCR latchup.
OTOH, if your pic had shown a very well connected low impedance ground and shielded setup, I'd begin to get a wee bit more skeptical.
Furthermore, you haven't even shown us the PC that all this gear was supposedly hooked up to...
Any chance that there was a 'dangling antenna or two' involved that could have picked up say a 2.4GHz signal?

Quite some time ago I had a client who was a 'compulsive tinkerer'.  He regularly ran his desktop with the side cover off (despite it being 'ill advised' to have such an abnormal airflow).  Oh yeah, he'd also overclocked it to the max too...  His complaint - Every time he switched on the WiFi access point, his system would freeze.
When I told him to put the side back on, the 'problem' miraculously vanished... GO FIGURE!
(SOMETHING inside the case was picking up the 2.4GHz WiFi signal and causing mayhem.  It wasn't worth wasting my time to analyse WHAT was acting as the receiver though.  Given that it was an older FULL SIZE ATX MoBo, I'm willing to bet that several PCB traces were beautiful 1/4 wave and / or 1/2 wave antennae)

[dannyf]

Yet another reason for me to not buy any more FTDI product.

It is always much easier to blame others.

It is always much more beneficial to you to not do that, however.

[leppie]

Seen and heard of these issues with some USB ports, mostly the 3.0 kind, but I have seen it on my PC acting weird on USB 2.0 ports too (was with STLink and AtMega U in my case).

Playing with different ports, I finally got it working without issue.

[retrolefty]

Anyway, the problem: When I hit the reset button on the Wifi module my adapter my PC completely locks up. I have to hit the reset button to get it back again. If I use the official Arduino USB-to-Serial adapter (Mega16U2 based, see picture) then there's no problem at all. I can reset all day long.

I have no idea why it crashes. The FTDI adapter isn't connected directly to the Wifi module, it goes via the Arduino Mega. Is it a burst of radio waves from the Wifi Module trashing the FTDI chip? I dunno but all the Arduino stuff survives just fine. Even is it was that, there's no reason to lock up the PC.

 I see only two wires from the mega to the FTDI module, if send and receive wires, where is the required ground wire?

[nitro2k01]

How are you powering the Aruino Mega? Does it have the same ground reference as the USB connection to the serial adapter, or is it powered from a wall wart or similar? Even if it's powered form the computer and you think "it shouldn't matter", have you tried connecting a ground wire between the Arduino and the serial adapter? Are there any series resistors or SMD ferrite beads on the serial lines on the FTDI adapter?

[Fungus]

I see only two wires from the mega to the FTDI module, if send and receive wires, where is the required ground wire?

It's a desktop PC so all USB connectors are connected to mains ground.

(Yes, I've checked...I can buzz continuity between any ground on those boards and a mains socket on the other side of the room)

PS: Yes, I tried adding a ground wire, it made no difference.

How are you powering the Aruino Mega?

USB. I just disconnected it to put it on the bench to take a photo.

[Fungus]

While I don't intend ever using an FTDI chip again, I'd suggest you look again at your own pic...
To my untrained eyes, you have several BEAUTIFUL antennae in that pic and, in combination with a bit of 'ground shift' due to cable resistance, could possibly even result in some SCR latchup.

(I did mention that as a possibility... haven't tried tinfoil yet)

It might be that but it doesn't explain why it only crashes when I press RESET.

I've tried moving the wires around so the FTDI adaptor is as far as possible from the WiFi. I covered the adapter with my hand. No difference.

Whatever: It shouldn't lock up my PC no matter what happens in the chip. There's definitely something wrong in FTDI's drivers if that can happen, and FTDI's defense for their actions was that their drivers were being (ab)used by other people.

[Fungus]

Yet another reason for me to not buy any more FTDI product.

It is always much easier to blame others.

It is always much more beneficial to you to not do that, however.

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

[victor]

Try to make it work without the driver intalled just as a dumb sub port see if it crashes

[Monkeh]

I see only two wires from the mega to the FTDI module, if send and receive wires, where is the required ground wire?

It's a desktop PC so all USB connectors are connected to mains ground.

Ah, so you'll have everything take a multiple-meter-long ground path, great plan.

Try to make it work without the driver intalled just as a dumb sub port see if it crashes

You can't use it without a driver.

[dannyf]

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.

[Fungus]

It's a desktop PC so all USB connectors are connected to mains ground.

Ah, so you'll have everything take a multiple-meter-long ground path, great plan.

Weird. I was always told the 'star' formation was the best...

PS: As already noted, it crashes with a GND wire as well.

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.

But none of those can show you photo ID.

[Electr0nicus]

I would've bet everything, that the missing ground wire from the FTDI board to the Arduino, would have been the problem. But as you said, it made no difference. Maybe you can try to hook your setup up to a laptop, if you have one. If it then works with the FTDI board, it's either a weird sort of grounding problem (because most Laptops aren't mains earth referenced), or the problem only affects your desktop PC.

Another thing i can think of is, that pushing the reset button creates some sort of spike on the power supply rail. Which then maybe affects the RS232 Driver inside the AVR and locks up the FTDI Chip and it's driver, locking up your PC.

Do you own a scope? Then you could try probing around what's going on on the RS232 lines power supply rail(s).

I don't think that it's RF influence from the WIFI. As the RF power should be 0 when the module is in reset. Try holding down the reset button for a long time f.e. 10 seconds and see if the PC locks up during that time, or only when you release the button, and therefore when the WIFI module starts transmitting.

Also a detailed Schematic of the Addon- Board you have made would be helpful, as the the cause of the problem isn't that obvious.
It would also be good to know the type of WIFI module used, maybe you can give us a link to a datasheet.
With the informations you have given us up to now, our help is more guessing than real actual help.

Cheers Gregor.

[sunnyhighway]

It might be that but it doesn't explain why it only crashes when I press RESET.
.
.
.
It shouldn't lock up my PC no matter what happens in the chip.

Crashing and locking up are two different things.
Could you elaborate on how it manifest itself on your computer? ( BSOD, kernel-panic, unresponsive application, mouse-pointer freezes, etc ? )

[Fungus]

Crashing and locking up are two different things.
Could you elaborate on how it manifest itself on your computer? ( BSOD, kernel-panic, unresponsive application, mouse-pointer freezes, etc ? )

It locks up.

Mouse cursor freezes, caps lock key doesn't make the keyboard light change, video stops playing.

[HackedFridgeMagnet]

Reinstall the driver.

Are you sure it is an FTDI chip?
What brand of adapter is it? Sparkfun?
Are the LEDs blinking?
Check with an oscilloscope, and/or USB sniffer.

Work out is it the the wired connection or data that is causing the problem or the proximity of the wireless.

Yes give it a ground connection cable.

[Fungus]

I would've bet everything, that the missing ground wire from the FTDI board to the Arduino, would have been the problem. But as you said, it made no difference.

There's a very solid ground connection between them. You can argue about the length of it, but it's there.

PS: That very length is also isolating the power supply of the FTDI chip. Any droop/spike in the Arduino/WiFi power is a long way from the FTDI chip. The only wires leading to the FTDI chip are RX/TX.

Also a detailed Schematic of the Addon- Board you have made would be helpful, as the the cause of the problem isn't that obvious.

See below. It's just an LDO and voltage divider for the 3.3V module.

The reset switch isn't on there because I added it after I drew the schematic. It's just a switch between the RESET pin and GND.

It would also be good to know the type of WIFI module used

http://www.electrodragon.com/w/Wi07c


We can go around in circles finding the cause but I fail to see how it's relevant to the FTDI driver locking up my PC.

I should be able to drive a nail through the FTDI chip and the worst that happens on the PC end is that the USB's power fuse kicks in and shuts off the 5V supply to that USB port.

[dannyf]

I fail to see how it's relevant to the FTDI driver locking up my PC.

I think the others are saying that you have not established that the FTDI driver crashed/locked up your PC.

[Fungus]

I fail to see how it's relevant to the FTDI driver locking up my PC.

I think the others are saying that you have not established that the FTDI driver crashed/locked up your PC.

a) What else could make the PC lock up like that?
b) Why would substituting the other USB to Serial adapter make the problem vanish?

[Monkeh]

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

A hardware fault no driver can handle.

b) Why would substituting the other USB to Serial adapter make the problem vanish?

Because you're changing the equation.

Stop 'working' on the assumption that a broken driver is the problem and find out what the problem actually is.

[sunnyhighway]

Crashing and locking up are two different things.
Could you elaborate on how it manifest itself on your computer? ( BSOD, kernel-panic, unresponsive application, mouse-pointer freezes, etc ? )

It locks up.

Mouse cursor freezes, caps lock key doesn't make the keyboard light change, video stops playing.

I assume your mouse and keyboard are both connected to a USB port as well.
USB ports don't work on HW interrupts but are always polled. Therefore it takes only 1 USB driver to behave badly in order to make all others suffer from it.


There is a way to proof the driver is at fault (unfortunately you can't proof the opposite this way).
 - Do whatever is needed to freeze the computer.
 - Disconnect the USB devices one by one until the keyboard and/or mouse become responsive again.
 - Now you have found the culprit.

[nitro2k01]

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. Maybe only USB communication is disturbed, causing the mouse and keyboard to stop working, (if they are connected over USB) but not the whole computer to freeze. Check for this even if the mouse and keyboard are not connected over USB. (Every different thing you try is another data point which may or may not turn out to be relevant.)

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. Again, this may cause the USB rail in the computer to shut off temporarily so the mouse and keyboard stop working. This particular scenario doesn't make much sense since it should freeze the computer regardless of the serial adapter,  but check for it anyway.

Otherwise, do the following start with your original setup, with all the wires hooked up. First confirm that you're still getting the freeze. Then try disconnecting one wire at a time and note if the problem stops occurring. Note which wire you removed to make it work. Plug it back in and try the other wires one by one, and also note if any other of the wires can cause the problem to go away. If all that fails try systematically disconnecting two wires at a time etc. 4 wires = 4 bits = 16 combinations in total.

Do you have any application running on the PC side for communicating with the device? If so, does the problem still happen if you're not running this program? If you have task manager open, which does the CPU usage spike when you press the reset button?

[Richard Crowley]

The fact that you HAVE a "solid ground connection" IS the problem.
You should NOT have a "solid ground connection" except from the FTDI board.
It sounds like you have a ground loop in your lash-up.
You couldn't have a "solid ground connection" in what we see in the photograph, so the problem lies elsewhere.

[free_electron]

I see only two wires from the mega to the FTDI module, if send and receive wires, where is the required ground wire?

It's a desktop PC so all USB connectors are connected to mains ground.

sure ... for dc ...

[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?

[Monkeh]

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.

So it's FTDI's fault that people take a load of cheaply designed and manufactured piles of crap and randomly plug wires into them?

[Fungus]

So it's FTDI's fault that people take a load of cheaply designed and manufactured piles of crap and randomly plug wires into them?

According to FTDI the reason people are cloning their chips is because their drivers are soooo good.

(That was one of their excuses for bricking everybody's chips...)

[dannyf]

So it's FTDI's fault...

Whether it is FTDI's fault or not doesn't matter here.

What matters is to blame FTDI for whatever fault there is.

[Fungus]

What matters is to blame FTDI for whatever fault there is.

Yes, that's the only reason I swapped out the FTDI chip that I was happily using in my project

(and many other projects before that).

[zapta]

So it's FTDI's fault that people take a load of cheaply designed and manufactured piles of crap and randomly plug wires into them?

'Cheaply designed', 'piles of crap' and 'randomly plug wires' are your own subjective labels, not facts. Not a good practice if you expect serious answers.

[zapta]

What matters is to blame FTDI for whatever fault there is.

They brought it on themselves.

[Monkeh]

So it's FTDI's fault that people take a load of cheaply designed and manufactured piles of crap and randomly plug wires into them?

'Cheaply designed', 'piles of crap' and 'randomly plug wires' are your own subjective labels, not facts. Not a good practice if you expect serious answers.

Out of this thread, I long ago stopped expecting anything but pointless, bandwagon FTDI bashing.

[dannyf]

There was zero attempt made to find out what the issue was;

There was every attempt made to pin it on FTDI, deservedly or not.

[Fungus]

There was zero attempt made to find out what the issue was;

I already told you why I'm not doing it this week - I need my PC to keep working, I don't need any weird crap happening that might take out the motherboard, corrupt the disk, or anything else like that. Feel free to donate another PC if you're in such a hurry.

There was every attempt made to pin it on FTDI, deservedly or not.

Even if it's deserved it'll be because my adapter is some cheap piece of garbage made in China, right?

[zapta]

Out of this thread, I long ago stopped expecting anything but pointless, bandwagon FTDI bashing.

Pointless? Even FTDI's CEO realized he was wrong and reverted that driver change decision.

[miguelvp]

Out of this thread, I long ago stopped expecting anything but pointless, bandwagon FTDI bashing.

Pointless? Even FTDI's CEO realized he was wrong and reverted that driver change decision.

So what is the point now?

[zapta]

[qSo what is the point now?

Beware of FTDI, hide your children. Why do you ask?

[wraper]

Even if it's deserved it'll be because my adapter is some cheap piece of garbage made in China, right?

Even if it did not deserve it'll be because it is FTDI, right?

[Fungus]

Even if it did not deserve it'll be because it is FTDI, right?

Ah, I think I see your problem...

Answer:

No. I'd stop using any brand of device that repeatedly locked up my PC. And I'd call them on it if they were claiming that the thing that distinguishes them from their competitors is "quality drivers".

[wraper]

This is not FTDI branded device. This is One hung low adapter with a chip calling itself ftdi. It might be counterfeit chip as well, if new driver don't kill it, doesn't mean that it is genuine. I'm aware of at least 2 types of clones: Chinese supereal and Belarus from Integral factory. But I don't think that it is even fake chip at fault but crappy schematic of that adapter and your super solid ground combined with another woodoo things. You even didn't answer if your pc crashes with driver not installed or not. IMO this is hardware fault that crashes the driver or entire usb hub.

[Fungus]

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....

[janoc]

Hello guys,

I think that whether or not the FTDI adapter is genuine or not is likely a red herring here. It is fairly easy to verify whether or not it works - if it tested out as "Genuine", then no matter whether or not it is really genuine, we can be sure that the machine communicates with it just fine.

I have the same Wifi module and I was testing them just two days ago with a FT2232H breakout board wired up with loose wires on my bench and it works just fine like that - so you can rule out the wifi interference as the likely cause too. Anyhow, that shouldn't cause a PC crash neither.

I have noticed two things:

1) Lack of ground connection between the FTDI adapter and the Arduino - bad bad, that will make things to not work correctly. But that shouldn't cause a crash.

2) Where is the whole shebang getting its power from? Through that single USB connection? If yes, then it is very likely that you are right at the edge of the power budget of the hub this is connected to. Those wifi modules are really power hungry, they require about 300mA of current by themselves. Add the current required by the power regulator, level converters on your gadget, the USB2serial bridge and whatever else you may have connected to the same hub (hint - mouse, keyboard ...) and you are easily running out of power (remember, USB specifies only 500mA per port from a *powered* hub!). Is this a laptop? That would make such power problems much more likely.

When you change the USB2serial modules, you exceed the power budget, the overcurrent protection of the hub kicks in and shuts things down. Now depending on the hub, it might shut down only the offending port, but many will shut the entire hub down, because it is simpler to implement (e.g. via a simple polyfuse). If this is a hub that is used to connect your keyboard and mouse too, then boom - your machine seems dead, Windows doesn't expect such situation neither and can go haywire, etc.

[Fungus]

I have noticed two things:

1) Lack of ground connection between the FTDI adapter and the Arduino - bad bad, that will make things to not work correctly. But that shouldn't cause a crash.

There's a ground via the USB cable - USB is always tied to mains ground (if available).

I tried an extra ground wire, it made no difference.

2) Where is the whole shebang getting its power from? Through that single USB connection? If yes, then it is very likely that you are right at the edge of the power budget of the hub this is connected to. Those wifi modules are really power hungry, they require about 300mA of current by themselves.

Yes, I know about the power requirements.

My USB ports can deliver 800mA each. USB ports and Arduinos have fuses in them against short-circuits/overloads.

Here's the Arduino schematic: http://arduino.cc/en/uploads/Main/arduino-mega2560_R3-sch.pdf

The fuse is the thing marked "F1" right next to the USB connector. It's a Bourns MSMF050-2 (500mA)

If this is a hub that is used to connect your keyboard and mouse too, then boom - your machine seems dead, Windows doesn't expect such situation neither and can go haywire, etc.

They will only 'die' until the fuse resets. There's no reason for Windows to crash, USB is designed for this. It's not just the USB, one time I had an EEVBLOG video playing when I pressed reset and it froze too. My keyboard is an old fashioned Model M that goes through a serial connector, not USB.

(PS: I'm pretty sure I've overloaded USB a couple of times over the last few years but I don't remember locking up the PC)

[janoc]

There's a ground via the USB cable - USB is always tied to mains ground (if available).

I tried an extra ground wire, it made no difference.

That ground via the mains earth is going to be extremely noisy. Furthermore, you are creating a ground loop, that will make the signal integrity even worse. It could even blow something up if there is a sufficient potential difference between the USB connectors (Arduino+your FTDI thingie) - e.g. if you decided to have the connections going to two different devices (such as a PC for the FTDI and a USB charger powering up the Arduino) connected to two different power outlets. The mains earth wiring may not even be connected on one side (e.g. the USB charger) or there could be easily tens of volts difference between the two outlets (especially in older buildings the wiring can be horrid!). In short, this is a major no-no and asking for big problems. Dave has a good video on the perils of mains earth wiring and how not to blow up your instruments, I strongly recommend you to check it out.

However, I agree, that should not cause a Windows crash like that, if things didn't go bang already then at worst you won't be able to talk to the chip.

Yes, I know about the power requirements.

My USB ports can deliver 800mA each. USB ports and Arduinos have fuses in them against short-circuits/overloads.

Here's the Arduino schematic: http://arduino.cc/en/uploads/Main/arduino-mega2560_R3-sch.pdf

The fuse is the thing marked "F1" right next to the USB connector. It's a Bourns MSMF050-2 (500mA)

Are you sure that the USB ports are actually able to deliver that current in your setup? If there are other things connected to the same hub already, they might not be. A good thing to make sure would be to connect this setup through an external, powered USB hub instead of directly to the PC. Alternatively, you can always power up the Arduino from a wall wart and get the 3.3V you need from its power regulator. That should be good enough.

The part about the polyfuse on the Arduino is not relevant - I was talking about the total current consumption at the point where this is connected to the PC - i.e. the USB hub. That includes all other hardware you may have connected to the same hub - e.g. a keyboard or your mouse. The polyfuse not tripping only tells you that the setup (Arduino + Wifi module) likely consumes less than 500mA (+- some tolerance, also polyfuses don't catch short power spikes). It doesn't "see" any current taken by the rest of your hardware that isn't connected through it - your FTDI adaptor, anything else connected to the same hub, etc. If you want to be sure, hook up your multimeter and measure the current through both the Arduino and the FTDI bridge USB connections (you may have to cut a trace on the board, cut up a cable or use a breakout box like this one:
http://archive.siliconchip.com.au/cms/A_112479/article.html).

They will only 'die' until the fuse resets. There's no reason for Windows to crash, USB is designed for this. It's not just the USB, one time I had an EEVBLOG video playing when I pressed reset and it froze too. My keyboard is an old fashioned Model M that goes through a serial connector, not USB.

I have an external hub that won't reset by itself after the short/overload is removed but you have to actually powercycle/disconnect it to get the dead port back - it uses a more advanced power management  solution than a simple polyfuse. Another one built into my monitor will stop working completely after a buggy device (i.e. not overload, it is a project I am working on) is connected and I have to powercycle it before the machine recognizes it again. So don't rely on it recovering by itself.

Re Windows crashing - if the hub is a motherboard hub, then Windows may simply not expect it to go offline - and then all bets are off. I have seen BSODs in such situations ... Could you check in the event log whether there is anything there after you restart the machine? Normally there should be an error logged if there was a problem. Also, it would really help if you could show the entire setup how is it connected to your PC, like this we are left guessing.

(PS: I'm pretty sure I've overloaded USB a couple of times over the last few years but I don't remember locking up the PC)

Yeah, it is weird. Try the setup with a powered external USB hub if you aren't using that already or a completely external power supply, without relying on USB power at all. That will allow you to rule out the power issues.

I have a powered USB hub on my bench for all USB connected hacking for that reason, I don't want to bust my mainboard or short the PC's PSU if I do something stupid like shorting the 5V rail by accident or sending 12V on the data lines by mistake.

[sunnyhighway]

Mouse cursor freezes, caps lock key doesn't make the keyboard light change, video stops playing.

They will only 'die' until the fuse resets. There's no reason for Windows to crash, USB is designed for this. It's not just the USB, one time I had an EEVBLOG video playing when I pressed reset and it froze too. My keyboard is an old fashioned Model M that goes through a serial connector, not USB.

These two data-points are solid proof the FTDI drivers are at fault.

Microsoft clearly states that a kernel-mode driver MUST return control to the kernel within 100 ms when it get a time-slice. Regardless if it needs more time or not in order to do what that specific kernel-mode driver needs to do. This rule must be obeyed in order to guarantee responsiveness of the operating system.
USB has no h/w interrupt, it can only do polling. Therefore it is impossible that interrupts are causing the OS to freeze. This makes the USB driver in fully responsible for locking up, regardless wheter the FTDI chip is talking rubbish simply refuses to answer, or completely swamps the USB port. I don’t even care what caused it, whether that being a floating ground, rfi or alien x-rays. This is the reason why kernel-mode drivers are littered with code for time-outs, just to obey that simple 100 ms rule. Forget one and you have a potential cause for a system wide freeze when the driver is waiting for something that may never happen.

Microsoft also states that kernel mode drivers MUST take extreme care not to allow for any buffer overrun, as kernel mode drivers have access to the full address-space and CPU registers. One tiny mistake and it could easily cause an endless loop or BSOD.

[marshallh]

During 2011 I discovered a case where under certain conditions unplugging a FT2232H based device with an outstanding endpoint transaction caused a BSOD on Win32. The problem has long been solved but weird cases aren't impossible. In OP's case I would suggest further testing on multiple computers to rule out the issue.

[Fungus]

That ground via the mains earth is going to be extremely noisy.

It's not via the fusebox in the basement, it's two USB cables plugged into the same PC. The maximum distance is a couple of meters. I wouldn't do it for (eg.) high-speed SPI but it works fine for RS232. The fact that I can buzz continuity from my Arduino to any mains socket in the house is just a bonus.

The part about the polyfuse on the Arduino is not relevant

If the USB ports can deliver 800mA and the Arduino's fuse is 500mA then I'd say it is. The Arduino should shut down first...

Could you check in the event log whether there is anything there after you restart the machine?

"The previous system shutdown at 12:57:50 PM on ?11/?3/?2014 was unexpected."
"The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly"

Nothing else.

[Fungus]

Mouse cursor freezes, caps lock key doesn't make the keyboard light change, video stops playing.

My keyboard is an old fashioned Model M that goes through a serial connector, not USB.

These two data-points are solid proof the FTDI drivers are at fault.

Good catch! I hadn't connected those two dots.

[HackedFridgeMagnet]

Mouse cursor freezes, caps lock key doesn't make the keyboard light change, video stops playing.

My keyboard is an old fashioned Model M that goes through a serial connector, not USB.

These two data-points are solid proof the FTDI drivers are at fault.

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


Maybe Fungus could start with the driver version and the OS version.
Then the FTDI board manufacturer.
Then he could say how he is so sure the IC is from FTDI.

It's a bit strange to be 5 pages into this thread and still basic but relevant information like this hasn't been given.

[Fungus]

Then he could say how he is so sure the IC is from FTDI.

It's a bit strange to be 5 pages into this thread and still basic but relevant information like this hasn't been given.

Precisely because there's no way to be 100% sure of this. As the tread has progressed it's become pretty cleat that no matter what I do/say, the naysayers will say it came from eBay therefore it must be fake/crap, therefore I'm at fault. QED.

And if it's not that it will be because my motherboard is causing the problem, not FTDI's driver, etc., etc. None of which can be proven either way.

...all the time ignoring that fact that swapping FTDI out of the equation without touching anything else made a consistent/repeatable problem vanish.

Rant over. Here's some info. Be sure to let us know what insightful information you got from it:

[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.

[Fungus]

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.

Nope. Only on hard reset of the Wifi Module.

With the exact same setup but using the Arduino USB-Serial adapter it's been working for a week without a single problem. Not one lockup for an entire week and I reset the Wifi module a LOT during that time (you have to reset it twice for every firmware upgrade and I spent the whole week tweaking the module's firmware).

[exapod]

It is the third time that i write this:
In my opinion is a ground loop problem.
1) Connect the ftdi to the pc .
2)connect the ftdi to the arduino mega with RX , TX and very important the GROUND.
3)power the mega with a battery or with the dc jack but not with the usb.
4)try resetting the wifi module to see what happens.
Please try it.

[Richard Crowley]

Yes, more than you have suggested that it is a ground loop problem.
But that seems to have been completely ignored.  This discussion is going nowhere.
Methinks that the OP would rather argue and thrash about than actually solve his problem.

[Fungus]

Yes, more than you have suggested that it is a ground loop problem.
But that seems to have been completely ignored.
Methinks that the OP would rather argue and thrash about than actually solve his problem.

Which part of "I did that, it makes no difference" are you failing to understand? 

It is the third time that i write this:

And for the third time: That photo isn't the only setup that was tried, believe me.

[Richard Crowley]

Which part of "it makes no difference" makes you think you DON'T have a ground loop?
That is the PRIME SYMPTOM of a ground loop!  Do you not understand what ground loop is?

[Fungus]

Which part of "it makes no difference" makes you think you DON'T have a ground loop?

That would be "the part where I tried eliminating ground loops".

Edit:

Just for you (and all the others) I've measured the voltage difference between the USB connectors on the FTDI adapter and the Arduino. It's 8mV. Make of that what you will.

I put in my shortest breadboard wire from the Arduino pin header to the FTDI pin header and it went down to ... 3.5mV. Woohoo!

[Fungus]

Right...

Last night I left my PC doing a backup (which needed doing anyway, I haven't done one for a while) and this morning I let Windows update install the latest FTDI drivers.

The problem is now much, much less. At first I thought it might be fixed, I reset the Wifi module a few dozen times and nothing happened, but .... not quite. After about half an hour of use I've had one lockup.

The lockup wasn't exactly the same as before: The mouse pointer stopped moving as usual but the CAPS-LOCK key kept working (Remember: Model M keyboard, not connected to USB).

It seems only the USB locked up that time, maybe the FTDI chip is asserting/holding a USB RESET condition or something?

I ended up having to hit the reset button just the same - I couldn't bring up Windows task manager with CTRL-ALT-DEL to do a clean shutdown.

So, summing up: It was FTDI drivers totally crashing my PC.

They may still be doing so. I'll give it a bit longer and if it happens again. I'm going back to the other adapter if it does.

[janoc]

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.

Right, but I doubt we would see this from the scope output. If the Arduino is "fighting" the output from the FTDI because of incorrectly configured pin, it would likely manifest itself as only a short spike. And he said he couldn't get it to trigger on CH1, so likely not happening. Anyhow, ATMega starts with all pins in high impedance/input mode, unless the code is doing something dumb, a short like that isn't likely.

 

[janoc]

@Fungus

You are a hopeless case, mate. I do wonder why did you even bother posting here when you know that your problem is that stupid FTDI driver (despite having no evidence ...), refuse to actually cooperate with people who are trying to help you out to debug your issue, when your lack of understanding is pointed out to you, you get defensive instead of trying to understand what is being said and only think we have you for an idiot ...

I am resting my case here, this is a clear waste of time. Maybe once you learn a bit more you will understand what a ground loop and USB power issues can cause.

Good luck.

[Fungus]

I am resting my case here, this is a clear waste of time. Maybe once you learn a bit more you will understand what a ground loop and USB power issues can cause.

The Arduino and FTDI aren't floating relative to each other, they're referenced to the same point. Agreed?

OK, we've measured an 8mV difference between the two when the Arduino is under load but an 8mV offset on a 5V RS232 signal isn't going to do anything (the noise on the signal is way more than 8mV - see 'scope image).

My question is: If 'grounding' is causing the crash, what's the mechanism?

(To me it seems like a knee-jerk response - 'grounding problems' are the root of all electrical evil, right? Second only to lack of decoupling capacitors...)

I'm happy to try things but not if it's just "try X and see if it does anything". What's the reason for doing it? Why would removing an 8mV offset on a TTL signal (or whatever) fix the problem?

[Fungus]

...what I mean is:

(in case it isn't clear)

Yes, there's a 'grounding problem' in the system, but:

a) Fixing it is more trouble than it's worth (am I supposed to start adding isolation transformers? What?)

and

b) How does an 8mV offset cause a problem on a TTL signal? How does it cause the PC to lock up? What's the mechanism in those two things?

PS: It seems to me that having a ground wire between the Arduino and FTDI adds to the problem, if anything.

[nitro2k01]

@Fungus

You are a hopeless case, mate. I do wonder why did you even bother posting here when you know that your problem is that stupid FTDI driver (despite having no evidence ...), refuse to actually cooperate with people who are trying to help you out to debug your issue, when your lack of understanding is pointed out to you, you get defensive instead of trying to understand what is being said and only think we have you for an idiot ...

I will acknowledge Fungus' point that the driver has to be at fault to some degree, and doing something bad when it could do something better, such as not returning control the OS or similar. This belief is also reinforced by the fact  that simply updating the driver (assuming no other changes were made) seems to have made the problem less likely to happen.

However, I believe there's a bunch of things that he could have tested, such as what I suggested above about disconnecting one serial wire at a time and see if the problem still happens. Examples:

Does the problem still happen if disconnecting only the TX line from the Arduino to the serial adapter, but keeping the RX line, and optionally ground wire, connected ? If so, then by a good first approximation the problem is with something transferred over that line, but there would be further steps to prove this.

Does the problem still happen when disconnecting both serial lines between the wireless module and the Arduino? If yes, then, this has to happen through some out-of-band communcation, such as radiated or conducted interference, or a short-circuit/power overload.

But there's still the off-chance that the FTDI driver is not the sole factor to blame, but that the problem comes from having the Arduino's serial driver loaded at the same time as the FTDI driver. Does the problem still happen if you reset with the FTDI module plugged in to USB, but fully disconnected from the Arduino? If so the likely culprit is a driver combination, but there are further steps to prove this beyond a reasonable doubt if that's where things are pointing.

All of the above steps would of course have to be done with the old driver (which can still be rolled back to the old version in Windows, btw.)

I'm seeing an inability, or more likely unwillingness, on Fungus' part to perform such steps and draw conclusions. I can understand not wanting to sink time into this, but in the same time, this is a missed opportunity for knowledge, which frustrates me.

[Fungus]

OK, I've just noticed something new.

I can reset the module just by touching a wire to the reset pin. No need to connect it to GND.

That implies a very weak pullup on that pin.

Maybe the Wifi module freaks out a bit when it's resetting (or something like that).

[Fungus]

I'm seeing an inability, or more likely unwillingness, on Fungus' part to perform such steps and draw conclusions.

Well,
a) I just don't like hard-resetting my PC. It makes me nervous.
b) I don't see any plausible theories to test.

PS: Yes, you need all the wires. Does that actually tell you anything?

But there's still the off-chance that the FTDI driver is not the sole factor to blame

Obviously something is happening to make it fall over... somebody would have noticed if FTDI adapters/drivers were just generally flaky.

The key question (to me) is why does it only happen when I reset the module. Everything works fine otherwise.

[Chris Jones]

I haven't read the whole thread but skimming over it I didn't notice anyone saying what I am about to, so in case anyone is interested:

I had the same problem (win7 laptop locks up, needs hardware power-off to get it working again).
https://twitter.com/chrisgj198/status/454591825970331649

This happened whenever my embedded microcontroller sent a XOFF (ctrl-S or ctrl-Q, can't remember which) to the PC. That was using driver version 2.8.14.0 with a FTDI cable from element14, (so the chip was probably genuine and certainly very expensive). I had been using it for a long time without sending XOFF characters and never had a problem. If anyone wants to replicate my settings it would have been 9600, N, 8, 1 and I would have looped back RTS to CTS on the cable (which I do by default) as well as setting the terminal to XON/XOFF flow control only.

The problem went away when I upgraded to a newer driver from FTDI's website. Not sure which version it was that I upgraded to, as it was a while ago.