-
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).
-
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.
-
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. -
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.
-
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? -
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!
-
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.
-
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.
-
@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.
-
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?
-
...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.
-
@Fungus
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.
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 ...
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. -
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).
-
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.
-
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.