Go Down

Topic: Serial communication stops after long periods. (Read 3981 times) previous topic - next topic

Twinsen

I use my Arduino as a remote control for my PC. It has a IR Receiver connected, it decodes the RC5 protocol and sends a character through the serial port.
My Arduino uses a FT232RL chip.
It works perfectly, except for the fact that after a long period of time(sometimes 30min, sometimes 3hours), it simply stops sending data through the serial port.
It continues to receive and decode the signals from the IR remote, but no longer sends them through the serial port. (the FT232RL "TX" LED no longer lights up).

This looks like a Windows driver problem to me.
Sometimes, disconnecting and reconnecting the USB cable fixes the problem, but many times, I can't even shut down the computer and have to reset it.

I have Windows 7 x64, and Virtual Com Port driver 2.8.17. (I have tested 2.08.14 and it behaves the same).
Has anyone experienced anything like this before?

Thank you in advance.

Here is my code just in case you need it.
Code: [Select]
int ir_pin = 2; //Sensor pin 1 wired through a 220 ohm resistor
int led_pin = 13;
int debug_pin = 11;    //"Ready to Recieve" flag, not needed but nice
int debug = 0; //Serial connection must be started to debug
int start_bit = 2000; //Start bit threshold (Microseconds)
int bin_1 = 1000;    //Binary 1 threshold (Microseconds)
int bin_0 = 400;     //Binary 0 threshold (Microseconds)
int data[12];


void setup() {
 pinMode(led_pin, OUTPUT);
 pinMode(debug_pin, OUTPUT);
 pinMode(ir_pin, INPUT);
 digitalWrite(led_pin, HIGH);
 digitalWrite(debug_pin, HIGH);
 delay(100);
 digitalWrite(led_pin, LOW);
 digitalWrite(debug_pin, LOW);
 delay(150);
 digitalWrite(led_pin, HIGH);
 digitalWrite(debug_pin, HIGH);
 delay(100);
 digitalWrite(led_pin, LOW);
 digitalWrite(debug_pin, LOW);
 delay(150);
 digitalWrite(led_pin, HIGH);
 digitalWrite(debug_pin, HIGH);
 delay(100);
 digitalWrite(led_pin, LOW);
 digitalWrite(debug_pin, LOW);
 Serial.begin(9600);
}

void loop() {
 int key;
 while(1)
 {
    key = getIRKey();    //Fetch the key
   //  Serial.print("Key Recieved: "+ key);
   if (key > 0)
   {
     //Serial.println(key);
     Serial.print(char(key));
   }
   else
   {
    digitalWrite(debug_pin, HIGH);
   }

 }
}


int getIRKey() {
 digitalWrite(led_pin, LOW);   //Ok, i'm ready to recieve
 digitalWrite(debug_pin, LOW);
 while(pulseIn(ir_pin, LOW) < 2200) { //Wait for a start bit
 }
 digitalWrite(led_pin, HIGH);
 data[0] = pulseIn(ir_pin, LOW); //Start measuring bits, I only want low pulses
 data[1] = pulseIn(ir_pin, LOW);
 data[2] = pulseIn(ir_pin, LOW);
 data[3] = pulseIn(ir_pin, LOW);
 data[4] = pulseIn(ir_pin, LOW);
 data[5] = pulseIn(ir_pin, LOW);
 data[6] = pulseIn(ir_pin, LOW);
 data[7] = pulseIn(ir_pin, LOW);
 data[8] = pulseIn(ir_pin, LOW);
 data[9] = pulseIn(ir_pin, LOW);
 data[10] = pulseIn(ir_pin, LOW);
 data[11] = pulseIn(ir_pin, LOW);

 if(debug == 1) {
   Serial.println("-----");
 }
 for(int i=0;i<11;i++) {  //Parse them
   if (debug == 1) {
       Serial.print(i);
         Serial.print(":");
 Serial.println(data[i]);
   }
   if(data[i] > bin_1) {  //is it a 1?
data[i] = 1;
   }  else {
if(data[i] > bin_0) { //is it a 0?
 data[i] = 0;
} else {
data[i] = 2;  //Flag the data as invalid; I don't know what it is!
}
   }
 }

for(int i=0;i<11;i++) {  //Pre-check data for errors
   if(data[i] > 1) {
return -1;     //Return -1 on invalid data
   }
 }

 int result = 0;
 int seed = 1;
 for(int i=0;i<11;i++) {  //Convert bits to integer
   if(data[i] == 1) {
result += seed;
   }
   seed = seed * 2;
 }
 return result;     //Return key number
}

Coding Badly

Quote
This looks like a Windows driver problem to me.


That is very very very unlikely to be the case.  There are thousands of people using the same OS, driver, and chip to shuttle significantly more data without problems.

Please describe the PC side program.

wayneft

If you ever figure it out please let me know because I've had the same problem for a long time!
I2C GPS Shield

Checkout my Open Source GPS Tracker on Kickstarter

PeterH

I don't know what's causing the problem, but since the PC is locking up that's where I'd start looking.

Can you find out anything from the Arduino side about what state it thinks the USB interface is in? Is it just not clear to send, or is there something else going on like a soft flow control?

While looking for the cause of the problem, I'd also consider more crude workarounds such as resetting the USB interface from either/both sides if it goes silent for an extended period. I decent watchdog and automatic reset can get you out of all sorts of grief. ;)
I only provide help via the forum - please do not contact me for private consultancy.

zoomkat

#4
Nov 05, 2011, 06:07 am Last Edit: Nov 05, 2011, 06:09 am by zoomkat Reason: 1
Simple test code for use with the serial monitor. Load the code, open the serial monitor, and let the program send the updates to the serial monitor. See how long the serial monitor will continue to update.

Code: [Select]

int x=0;

void setup() {                
 // initialize the digital pin as an output.
 // Pin 13 has an LED connected on most Arduino boards:
 Serial.begin(9600);
 pinMode(13, OUTPUT);    
}

void loop() {
 digitalWrite(13, HIGH);   // set the LED on
 delay(2500);              // wait for a second
 digitalWrite(13, LOW);    // set the LED off
 delay(2500);  // wait for a second
 x=x+1;  
 Serial.println(x);
}
Google forum search: Use Google Advanced Search and use Http://forum.arduino.cc/index in the "site or domain:" box.

Twinsen


Please describe the PC side program.


The PC side program is not the problem.
I have this issue when using putty to connect to the com port, and even when no application are connected to the com port. At some point, when using the remote control, the FT232RL "TX" LED no longer lights up.

Now I'm running zoomkat's code. I'll see how it behaves. It's hard to do extensive testing, because many times it takes up to 4 hours for the problem to happen.

Twinsen

#6
Nov 05, 2011, 05:09 pm Last Edit: Nov 05, 2011, 05:12 pm by Twinsen Reason: 1
oook...
I was testing serial communication with the simple code from zoomkat, and I found what was causing this: the refrigerator... that's right, the refrigerator...

This might seem like a bad joke, but I replicated this 4 times today and I didn't believe it either. Every single time the refrigerator turns off, the serial connection just breaks.

The only connections is that the computer and the refrigerator is plugged in the same wall socket.
Being an old fridge, I'm guessing an electric impulse is sent through the wall socket, through the power supply, and somehow messes up the USB port.

Still looks like a driver problem to me. The driver does not behave correctly when it gets interference through the USB cable.

Any other ideas? Any way to fix this? This shouldn't be happening obviously, since all other things plugged in the USB ports and all of the computer components work perfectly.

dxtinct

Hi i have the same problem.

I see this is only related to arduino uno, as my program is working already for aprox 5 days on arduino duemilanove.

The problem is that i'm building an Andon sistem , and i print on serial the production line status, as messages like, "x" , "a", "f" and i need this messages to always be recieved.
I manage to reset the Arduino Uno Board with watchdog timer, and to trigger an wtd_reset every let's say 1 hour, but the fact all the program variables initialize to 0 this also not quite the solution in my case.
Anyone having other ideas ?

I really feel that the milis() counter gets too big and then the board stucks somehow, but i can't understand why Arduino uno hanges after some random hours amount compared to Arduino Duemilanove.

I also have almost 10 Arduin uno's that I would like to use.

Thank you.

sbright33

I had a similar problem.  The TX light stops blinking.  The Sketch continues to run, but the PC doesn't see the data.  It has something to do with the USB chip on the Uno.  When you run the same sketch on a Pro mini using only 1 wire connected to the serial TX, obviously an LED will still blink if you connect one.  You can read this data with serial TTL to USB converter.  I'm not saying the USB chip is defective or stops on it's own.  It's reacting to something on the PC.  Perhaps closing the PC port inadvertently.  I'm going to say something obvious here:  Something is changing on the PC causing this to happen after a few hours.  You can prove this by disconnecting the USB cable, then restarting the sketch without it.

A power surge from the refrigerator could effect the USB chip without resetting the 328?
If you fall... I'll be there for you!
-Floor

Skype Brighteyes3333
(262) 696-9619

Nikarus


oook...
I was testing serial communication with the simple code from zoomkat, and I found what was causing this: the refrigerator... that's right, the refrigerator...

This might seem like a bad joke, but I replicated this 4 times today and I didn't believe it either. Every single time the refrigerator turns off, the serial connection just breaks.

The only connections is that the computer and the refrigerator is plugged in the same wall socket.
Being an old fridge, I'm guessing an electric impulse is sent through the wall socket, through the power supply, and somehow messes up the USB port.

Still looks like a driver problem to me. The driver does not behave correctly when it gets interference through the USB cable.

Any other ideas? Any way to fix this? This shouldn't be happening obviously, since all other things plugged in the USB ports and all of the computer components work perfectly.


Actually it might completly be the fridge. I recall a couple months ago a person was having some trouble with a machine that would monitor the temperature of some beer storage I think, and then use that to control when to turn on the refridgeration. But it kept breaking down because they eventually found out the fridge was causing the problem. Try connecting the fridge into a socket a little farther away and running it. Honestly thats what the other guy ended up doing to fix it. I'll find that forum a little later and link it to you if you don't believe me.

AdeV

Run the PC through a small UPS - that should completely eliminate any talk between fridge & PC.

Vivio

Hello,

The same thing happens to me: "TX" LED no longer lights up, but this happens in less than a minute if I send through com port
almost 40 characters at 100ms.

Probably it has something with x64 OS, mine is win 8.1 x64. After updating the FTDI drivers I was able to get around 2-minutes of consistent output.

On a Win Xp machine, with different code, though I haven't got issues :(

#12
May 27, 2014, 05:28 am Last Edit: Oct 10, 2014, 02:32 am by snakethumper Reason: 1
I had an identical issue.  The port would stop sending after a long time.  This would typically be around 2 to 6 hours. At first I was convinced it was spikes on the mains supply causing the Arduino Serial Port Chip to stop working, so I spent a fair bit of time beefing up my power supply. But that didn't fix it. I was on the verge of swapping out the Arduino itself when I thought perhaps there was something going on with the USB ports themselves and so being without a spare Arduino Mega, I decided to investigate that first.

Turns out (in my case) that the USB ports was the problem. I had a USB mouse connected to a motherboard backplane (main) USB port, and the Arduino connected to an "extension" or "extra" USB port hanging off another header off the Mobo. What I did was move the mouse to another Extension port, then moved the Arduino to one of the main backplane ports. Bingo ! - no more problems and it hasn't faulted since. I don't know if its possible for 2 USB ports to have some kind of resource conflict, but it certainly seems that way to me.

Anyway I relate all this just in case it helps someone....

Cheers
David

Update: 10 October 2014 - Its happening again. I now have 2 Mega's: a 1280 and a 2560. The problem occurs on both.  Back to the drawing board to try to find out what is going on here. Note: On the PC I've tried Power Options->USB Settings->USB selective suspend (Disable), still no good. Will update here again if I have any more info to share....

David

Go Up