Arduino stops sending data to the serial port after a long time period

Question

I am using an Arduino Uno rev2 device as a permanently connected device that sometimes sends signals to a PC (Windows 7 x64). Code compiled with Arduino 1.0 software from arduino.cc

Topic on arduino.cc, Arduino stops sending data to Serial after a long time period

Souce code

It works perfectly but sometimes, after a long period of time, the PC stops receiving data from the Arduino device. It is not a PC software issue, as all software(putty, telnet, etc..) acts the same - I can send data TO the Arduino (the device responds to commands); I just can't receive it back.

A similar problem was described here in Serial communication stops after long periods., but no solution was suggested.

Disconnecting/connecting the device solved the issue temporarily, but this can't be a solution, as the device is supposed to be used permanently and fully automatically.

Using board reset button that resets program & all values to it's start wont help. Data does not start to be being received by PC.

Notes:

1. millis() rollover bug is not reproducable on Arduino Uno board with Arduino 1.0 software - I guess this was fixed and millis() now do really rollover only in 50 days, like it is said in documentation. Besides code has millis() independent code that is not responding too.

2. LED that is blinking during sending data to PC still blinks.

3. Strings usage could increase memory usage, but this program is way too small for that to be a problem. No additional memory was used after 10+ hours of program running, so I'm not really going to bother with replacing Strings with something else, as Serial port problem is far more major.

If you think that the problem is in arduino program bug, please think of how to explain TX blinking & reset not helping.

Solution

Perhaps making a software reset your problem would be solved. I ran the following code to find out if a software reset would reset the clock and therefore the millis() function:

void setup()
{
  Serial.begin(9600);
  Serial.println("Will start sending millis values in 5 seconds...");
  delay(5000);
}

void loop()
{
  Serial.println(String(millis()));

  if (Serial.available() > 0)
  {
    if (Serial.read() == '@')
    {
      Serial.println("Rebooting. . .");
      delay(100); // Give the computer time to receive the "Rebooting. . ." message, or it won't show up
      void (*reboot)(void) = 0; // Creating a function pointer to address 0 then calling it reboots the board.
      reboot();
    }
  }
}

As explained in the code, to make a software reboot simply create a function pointer to address 0 and call it. I, indeed, had satisfactory results:

Will start sending clock values in 5 seconds...
5000
5000
5000
5001
5001
5001
5002
5002
5002
. . .
6804
Rebooting...
Will start sending millis value in 5 seconds...
5000
5000
5000
5001
5001
5001
5002
5002
5002
5003
5003
. . .

I hope this solves your problem :)

Comments

[Max The Cat]

Resetting board wont solve the problem. Only hardware reconnecting USB restores data receival.

[Max The Cat]

1. According to documentation millis() owerflow in 50 days. And I use (unsigned long) in my code 2. board wont recover sending data after being reset 3. boards blinks with TX led => that is not the issue

[wildplasser]

From the link to the forum (reply#2) : "The counter is an unsigned long. At 16Mhz, that's 550 seconds, which is about 9 hours."

[Max The Cat]

Yes, I'm aware about bad code :) I'll try implementing rollover detecting and one more output function that wont use timer at all. Though it WONT EXPLAIN RESETTING PROGRAM WONT HELP. RESET resets all variables to zero and restarts program from very start, doesn't it? But RESET wont recover serial connection.

[Max The Cat]

millis() DOES reset when board is RESET.

[toonice]

This could be a more useful Answer if you were to expand upon why you cannot execute commands after a few hours and how you can solve the problem without having to reboot periodically (which is the main thrust of their question). Suggesting helpful modifications to their code would also be a plus, as would references to any related reference sources (including links) that are likely to shed more light on the situation.