Upload & Monitor and Test find wrong serial port for Arduino Leonardo, others

Configuration

Windows 10, also OS X 10.14:

PlatformIO Version (platformio --version): PlatformIO, version 4.1.0b3

Description of problem

“Upload & Monitor” and “Test” will open the wrong serial port on devices such as the Arduino Leonardo or Adafruit M0 & M4 devices that use a software USB interface that re-enumerates after uploading a new program.

Steps to Reproduce

1. Set up project with code below
2. Try “Upload & Monitor” and get either wrong serial port, or error.
3. Try “Test” and after code uploads get wrong serial port, or error.

Actual Results

Depending on configuration upload & monitor or test fail in one of the following ways:

• You’re prompted for which serial port to use, with a stale list of devices by the time you choose one.
• The wrong serial port is chosen, if for example you have another serial device besides the device. On OS X this is often the bluetooth serial port, so the test output will never appear.
• Windows cannot find the file specified if you specify the corresponding monitor_port or test_port

Expected Results

Platformio should wait until the device enumerates again and choose the correct serial port.

If problems with PlatformIO Build System:

The content of platformio.ini:

[env:leonardo]
platform = atmelavr
board = leonardo
framework = arduino
;monitor_port = COM10
;test_port = COM10

Source file to reproduce issue: src/main.cpp

#include <Arduino.h>

void setup() {
  Serial.begin(9600);
  pinMode(LED_BUILTIN, OUTPUT);
}

void loop() {
  Serial.println("On");
  digitalWrite(LED_BUILTIN, HIGH);
  delay(1000);
  Serial.println("Off");
  digitalWrite(LED_BUILTIN, LOW);
  delay(1000);
}

test/test_main.cpp

#include <Arduino.h>
#include <unity.h>

// void setUp(void) {
// // set stuff up here
// }

// void tearDown(void) {
// // clean stuff up here
// }

void test_led_builtin_pin_number(void) {
    TEST_ASSERT_EQUAL(13, LED_BUILTIN);
}

void test_led_state_high(void) {
    digitalWrite(LED_BUILTIN, HIGH);
    TEST_ASSERT_EQUAL(HIGH, digitalRead(LED_BUILTIN));
}

void test_led_state_low(void) {
    digitalWrite(LED_BUILTIN, LOW);
    TEST_ASSERT_EQUAL(LOW, digitalRead(LED_BUILTIN));
}

void setup() {
    // NOTE!!! Wait for >2 secs
    // if board doesn't support software reset via Serial.DTR/RTS
    delay(2000);

    UNITY_BEGIN();    // IMPORTANT LINE!
    RUN_TEST(test_led_builtin_pin_number);

    pinMode(LED_BUILTIN, OUTPUT);
}

uint8_t i = 0;
uint8_t max_blinks = 5;

void loop() {
    if (i < max_blinks)
    {
        RUN_TEST(test_led_state_high);
        delay(500);
        RUN_TEST(test_led_state_low);
        delay(500);
        i++;
    }
    else if (i == max_blinks) {
      UNITY_END(); // stop unit testing
    }
}

Additional info

If I configure monitor_port or test_port then I get the “cannot find file specified” error in windows.

If I don’t, then I will get a serial error on upload & monitor because it chooses the leonardo programming serial port which disappears when the leonardo reboots.

Here’s some other people probably hitting the same issue:

• https://github.com/platformio/platform-atmelsam/issues/45
• https://community.platformio.org/t/teensy-unit-testing-doesnt-execute/8101

[elguiri]

If anybody else has this issue prior to a fix, there is a workaround described here… https://community.platformio.org/t/any-way-to-configure-timeout-for-upload-monitor/3812

[sphereinabox]

Yeah, Upload alone works fine, and Monitor alone works fine, there’s just the race condition when trying to do one then quickly do the other on these devices that do software USB serial.

I think get_test_port() for example should:

• If there is a test_port or monitor_port configured, then use the retry & timeout logic instead of immediately trying and failing to open that port after uploading code.
• If the hardware has USB device IDs for serial, then I don’t think platformio should to be trying to connect with serial ports that don’t match these device IDs. In particular platformio should wait to find the leonardo or whatever instead of connecting to the always-there /dev/cu.Bluetooth-Incoming-Port or maybe I should be able to blacklist /dev/cu.Bluetooth-Incoming-Port

If I were to make a pull request with the changes I propose, which branch should I start from?