3

I'm using a LinkIt ONE Arduino-like to send sensor data via MQTT.

It always worked very well, then out of the blue, it stopped printing anything using Serial.print();

But if I ommit the "Serial.begin(9600);" line, the code runs normally, sending sensor data via MQTT, even if I can't see debug output.

This shows the problem is on the Serial handling.

Since I can't show the entire code here, here's two test cases:

1.

void setup(){
  Serial.begin(9600);
  Serial1.begin(9600);
  while(!Serial); //Wait until Serial is ready before printing
}

void loop() {      
  Serial1.println("This came from serial 1"); //does nothing
  Serial.println("This came from serial 0");  //works
  delay(1000);
}

It shows me the following output:

This came from serial 0

This came from serial 0

Thi

Looks like the module freezes before the third iteration.

But if I omit the lines that aren't printed, from Serial1:

2.

void setup(){
  Serial.begin(9600);
  while(!Serial);  //Wait until Serial is ready before printing
}

void loop() {
  Serial.println("This came from serial 0");  //works
  delay(1000);
}

No output is shown on Serial monitor.

What is the reason behind this? Since Serial1 prints nothing, why can't I remove it?

Observations:

I tested the code in two LinkIt ONE modules of the same model.

I tested it in Arduino SDK 1.6.8, 1.5.6r2 and 1.6.5.

Edit:

Just made another test using the code below. It blinked two times showing that

Serial.begin(9600); runs

while(!Serial); runs (it didn't freeze the module waiting for Serial to initialize)

But Serial.println(); freezes

void setup(){
  pinMode(13, OUTPUT);
  blink();
  Serial.begin(9600);
  blink();
  while(!Serial); //Wait until Serial is ready before printing
}

void loop() {      
  Serial.println("This came from serial 0");  //works
  blink();
  delay(1000);
}

void blink(){
  digitalWrite(13, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(13, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);
}
4
  • If the test code you posted is truly failing, you either have some external problem, or you have an issue you need to take up with the vendor of this non-Arduino board. May 16, 2016 at 17:06
  • @ChrisStratton I have another friend that has the same board and will make a test using the same code, this is extremely weird because I tested it in two different boards and 3 different versions of Arduino IDE. Anyway, I'll keep you posted. May 16, 2016 at 20:58
  • @ChrisStratton I reinstalled arduino IDE from scratch on version 1.6.9 and installed the lastest firmware version available 1.1.21, from board manager, that solved the problem. Should I put this as an answer to my own question? May 18, 2016 at 13:13
  • If the problem is solved, then by all means post an answer.
    – Nick Gammon
    May 20, 2016 at 6:08

3 Answers 3

1

The problem was solved by:

  • making a clean install of Arduino IDE 1.6.9
  • uploading the LinkIt SDK on board manager from version 1.1.17 to 1.1.23.

Then the Serial function returned back to normal.

0

I have bit similar problem. I thing, this is arduino bug. When start serial port, must be take out data from Rx. When read buffer overflow my arduino freeze. I can't run delay because when arduino wait, serial port can receive lot of data -> overflow -> freeze. Instead of delay I use own function wait(milis):

void wait(unsigned long wait_time){
  unsigned long start_time;
  start_time=millis();
  while ( millis() < (start_time+wait_time) ){
    if (serial.available() > 0) serial.read();
  }
}
1
-1

This shows the problem is on the Serial handling.

The problem isn't actually in Serial, it's somewhere else. Many things are able to make the Arduino hang in mid-write. Show us the any code that you have written, plus links to the libraries you are using, and you'll have your answer in short order.

I will guess that you have a low-RAM condition, perhaps exacerbated by heap usage. Do you use String? I notice you're not using the F macro to save RAM.

5
  • 1
    You seem to be overlooking the fact that the code is not running on an Arduino. It is running on an entirely different, marginally source compatible board with orders of magnitude more resources. The F() macro exists in response to the ATmega's unusually pure Harvard architecture. May 16, 2016 at 17:03
  • @ChrisStratton, Right, this board doesn't need F. However, I will stand by the guess (low RAM) and the request for the whole program. I hope you aren't suggesting that "more resources" keep him from using RAM poorly? Or that his trivial excerpt contains the problem? Seems like an XY question to me...
    – slash-dev
    May 16, 2016 at 20:39
  • 1
    You really should look up how much ram the board has before you make such extremely unlikely guesses and then insist on "standing by" them - debugging is about facts and evidence not unfounded guesses. Also keep in mind that we have code in the question that can allegedly cause the problem. May 16, 2016 at 20:49
  • A made a test using the F macro, and it did not work. Then, I made another test using the following code: May 16, 2016 at 21:06
  • Nevermind, I will edit the question. May 16, 2016 at 21:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.