SparkFun Forums 

Where electronics enthusiasts find answers.

Have questions about a SparkFun product or board? This is the place to be.
By finnkerr
#183399
Hello all,

Basically, I am unable to send the Pro Micro 3V anything over serial.

I am receiving data from the board just fine (in fact, it doesn't matter what I set the baud rate to, it seems to adjust every time I connect), but sending anything through the Arduino serial monitor causes it to freeze up until I unplug the Pro Micro.

Using a different serial monitor (Realterm) showed much the same results, except that the freezing was handled better and I just kept seeing the incoming serial data, suggesting it's an issue with the Pro Micro or the Pro Micro drivers.

The LED on the board doesn't light up when I send any commands, suggesting nothing is reaching the board to begin with.

The sketch itself is pretty straightforward. It constantly outputs sensor values (everything seems correct here) until I send a command, when it should stop and send something else. The Pro Micro doesn't seem to be receiving the command and just keeps outputting the sensor values. Fairly sure it's not a code issue though, given the results above and that the code works flawlessly on a Nano.

What can I do to further troubleshoot?

System: Windows 7 Pro x64
Arduino IDE: 1.6.4

EDIT:
Here's the truncated code:
Code: Select all
#include <SPI.h>
// a few sensor libraries go here

// a ton of variables go here
boolean start = true;
int loopDelay = 20;

void setup() {
  Serial.begin(115200);
 
  //initializing stuff for the sensors (SPI)

  delay(1000);

}

void loop() {
  
  if (start && millis() - last >= loopDelay)
  {
    last = millis(); // this is just to keep track of the last loop run, mostly to give the sensors time to get new values
    
    String output = "";
    
    // several sensor and calculated values added to String output
    
    Serial.println(output);
  }
  // for debugging
  if (!start)
    Serial.println("Stopped");
}


void serialEvent(){
  if (start)
    if (Serial.available() > 0)
      if ((char)(Serial.read()) == 's')
        start = false;
}
Last edited by finnkerr on Mon Jul 20, 2015 5:34 pm, edited 2 times in total.
By Valen
#183429
finnkerr wrote:...
The sketch itself is pretty straightforward.
....

What can I do to further troubleshoot?
Sorry that doesn't get you off the hook. Mistakes come in all sizes of programs. Show the code.
By finnkerr
#183499
Thanks for the reply @Valen
Valen wrote:Sorry that doesn't get you off the hook. Mistakes come in all sizes of programs. Show the code.
Fair enough, code's been added to original post. I took out anything that wasn't relevant to serial communication (there's a ton of it). I checked the libraries and none contain any lines that have anything to do with serial.

Valen wrote:The simple cause might be that you are sending or expecting the command to come through the wrong serial port.
The only place I see that as a possibility is in the serialEvent() function. Is this not the correct one for USB? Also issues with the Arduino code wouldn't explain the freezing serial monitor nor the Pro Micro RX LED not lighting up.
#183509
Problem solved!

The issue seems to be that the handling of serial events wasn't triggering the serialEvent() function. Adding the following to any sketch that contains serialEvent() makes it work for me:
Code: Select all
void serialEventRun(void) {
  if (Serial.available()) serialEvent();
}
This solution was found on the following Arduino forum topic for the Due, but apparently the Pro Micro has the same issue:
http://forum.arduino.cc/index.php?topic=135011.0

Another solution is just to change serialEvent() to serialEventRun()
By Valen
#183511
Ok, good that is it working.

As for posting code with removed non-relevant parts, I'm not a big fan of that. You risk messing up the entire structure by removing too many curly or round brackets, thereby introducing bugs in the source code that didn't exist before. Also, it would obscure any time-dependant or race-condition issue in the original code. You may think you are reducing the complexity, but in the process you could be hiding the issue. A bit more time spent untangling the spaghetti is my preference.