It hasn’t got anything to do with your problem, but one thing I’d change is this
while (Serial.available() && Serial.read()); // empty buffer
Since this doesn’t necessarily do what the comment suggests. If you do receive NULL bytes your while will leave, but any other present bytes will be left in the buffer.
I’d go for
while (Serial.available()) Serial.read(); // empty buffer
And in the
while (!Serial.available()); loop I’d add a
Spark.process() call, just to be safe if there is a longer periode without
I also wouldn’t do this in
// if programming failed, don't try to do anything
if (!dmpReady) return;
If programming succeeded you’ll impact your default program run. I’d rather use a
while (true) Spark.process(); inside the fail branch in
As for your serial problem, just try to do this in your
// initialize serial communication
Spark.process(); // wait for data
This way your program will wait inside that
while() till your serial monitor gets connected and you provide at least one byte.
That also should allow OTA flashing after a normal button reset, without the need for a hard reset.
One other thing with Windows and USB serial is, that you shan’t try to open the port before the device got propperly recognized and the driver hooked up - listen for the attach sound and wait a second
And you should close the port before detaching/resetting the Core otherwise it will come back on a different port number.
Another reason for not being able to flash OTA might be that your code gets stuck somewhere - e.g. blocking calls of your libs.
Do you see any indication for this on the RGB LED? Just add some cloud features like
Spark.variable to check cloud accessability.