Board keeps running, but serial connection fails.

Hi everyone,

I have been struggling with a problem with the serial communication from the Seeeduino Mega to a USB port on a PC.

The program basically runs some pumps, solenoids (all 5V externally powered relays) and sends (lots of) data via "Serial.print" to the PC.

We run the program for long periods of time (e.g. 10 days). The problem is that the board will keep running, program/process still looks good, but the serial connection will hang up, leaving us with no data (even though the device is still running)! OH NO!

The suspicion is a power issue... We have added the 4.7uF cap to the FT232RL USB Serial chip, added delays and inductive kickback protection, etc. BUT the problem still remains.

The questions are: why does the chip keep running but the serial connection fail? Is it an FTDI driver problem? A windows USB problem? A power problem? A code problem? Is there a way to modify 'Serial.print' to add some sort of code integrity (make sure the data is sent before the program continues)?


For reference, here is the data logging code:

void logdata(){ time(); if(logon == 1 && milli >= datatake){ //


if(dataheader == 0){ Serial.println(",,Time(s),cycle time,State,tds1,I1(mA),I2(mA),tds1ai,"); // tds2, removed after tds1 ... tds2ai, removed at end dataheader = 1; }

Serial.print(","); Serial.print(milli/1000); Serial.print(",");

if(currentstate == 170 || currentstate == 172 || currentstate == 270 || currentstate == 272){ unsigned long haha = ((milli - (cyclestop - (cycletimer * 60000)))/1000); Serial.print(haha); Serial.print(","); } else{ Serial.print(","); }

/*************** KASHIF *******/ Serial.print("[");

Serial.print(prevstate[5]); Serial.print(",");

Serial.print(prevstate[4]); Serial.print(",");

Serial.print(prevstate[3]); Serial.print(",");

Serial.print(prevstate[2]); Serial.print(",");

Serial.print(prevstate[1]); Serial.print(",");

Serial.print(prevstate[0]); Serial.print(",");

Serial.print("]"); /***********************/

Serial.print(currentstate); Serial.print(",");

//Serial.print(""); Serial.print(tds1average); //Serial.print(""); tds1average = 0; // reset tds1average so as to match the datalog rate tds1acc = 0; tds1total = 0; Serial.print(",");

power1state = map(power1state, p1_AI_low, p1_AI_hi, p1_real_low, p1_real_hi); Serial.print(power1state); Serial.print(",");

power2state = map(power2state, p2_AI_low, p2_AI_hi, p2_real_low, p2_real_hi); Serial.print(power2state); Serial.print(",");

Serial.print(tds1ai); Serial.print(",");

time(); datatake = milli + datarate;

Serial.println(equastop); delay(10);

Serial.flush(); } }

Does the Sketch recieve data?

What is running on the PC side?

The sketch only reads data from digital/analog inputs on the chip... no serial data.

On the PC side, we are just looking at the Serial Monitor window.


If you are only writing data at some specific interval, why do you need a delay?

If you are not reading serial data, why do you need to flush the incoming data buffer?

The version 0019 Serial Monitor gets a bit flaky after a “large” amount of data has arrived. Eventually, it requires Death by Task Manager to get it shut down. I suggest trying another terminal application.

Lately, I’ve been using this…

…but I have no idea how it behaves with large amounts of data.

@Paul S, yes these lines are unnecessary. We added these just in case... I saw something about how the serial.print command returns before sending it's last character, so MAYBE the delay would have worked (?) but problem still persists.

@Coding, I am using version 0021... I will try the app you linked to, thank you.

I still suspect that it's some issue between the FTDI chip and the USB port/handling.

I should add that the serial connection crashes after inconsistent periods of time.

Thanks for the suggestions, we are determined to fix this!

Do you have any blue tooth devices/services that might be commandeering the port?

Do you have a screen saver or power saver that kicks in after a period of inactivity by input devices?

The Seeeduino Mega has both sending and receiving serial data leds wired to the FTDI chip. If the led is still showing activity that would point to the PC side, if not then your sketch should be the place to look.


@PaulS, No BT, I turned off all the screen saver/power saving/ port suspension stuff in Windows....

@retro, I will look at those LED's next time it freezes.

Updates to come...

Luckily, it just froze (how convenient!) and I was able to see that the Tx LED was SOLID. :-/ Any ideas?

Any ideas?

Sure, find and fix the bugs in your code. ;D

I'm not a software guru, but I'm always suspicious of the use of the serial.flush statements, they tend to me be a catch all for sloppy coding. If you don't have a specific reason for using serial.flush then just comment them out and see if the symptom changes or goes away. Just a gut idea but easy to try.