I’m using Platformio in vscode on a Mac with a adafruit_feather_nrf52840 board. I have a simple program that does a Serial.println(“hello”) each second, controlled by a Delay(1000).
Every time I build I am presented with the menu:
Executing task in folder Photon2 Firmware: platformio device monitor <
— Available ports:
— 1: /dev/cu.Bluetooth-Incoming-Port ‘n/a’
— 2: /dev/cu.ChristophersiPad-Wirele ‘n/a’
— 3: /dev/cu.headphones-SPPDev ‘n/a’
— 4: /dev/cu.headphones-SPPDev-1 ‘n/a’
— Enter port index or full name:
The serial port is not automatically selected and none of these options are the device serial port.
When I use PlatformIO:Serial Monitor toolbar button to reopen the monitor I’m presented with a dialog to terminate or restart the serial monitor. If I choose restart it now starts showing the monitor output.
This happens on every build.
Why is the serial port not being created and selected after a build?
I have this in my platformio.ini file:
monitor_speed = 115200
My program is;
void setup() {
Serial.begin(115200);
}
void loop() {
delay(1000);
Serial.println(“hello”);
}
So after digging in the forum I found a clue to answer my own question: Apparently VS Code can’t automatically terminate a process. If the serial monitor is running it’s necessary to manually kill it before uploading the program again.
To kill the monitor click the trash can in the upper right of the console area. Then after the upload you need to restart the monitor by clicking the PlatformIO:Serial Monitor toolbar button.
This can cause you to miss the first few seconds of monitor output. If this matters to you, insert a delay. e.g.
void setup() {
Serial.begin(115200);
delay(5000); //delay five seconds.
}
This works for me. I’d welcome suggestions on a more convenient way to do it…
If you upload to your board whilst the serial monitor is already open, it does not successfully reopen. This is not a PlatformIO issue per se, but an issue with how fast your board is detected by your OS / computer after it resets. When PlatformIO restarts the serial monitor, if the device hasn’t been detected yet, it can’t auto-select it, and thus will also not not be in the list of devices to choose from. To mitigate this issue, you can increase the wait time before the serial monitor is restarted, so your computer has time to re-detect it before PlatformIO tries to access it. In the extensions panel, click on the gear icon to get to ‘Extension settings’, and then try something like 1000 (1000 milliseconds or 1 second) to start with, and see if that is enough time. If not, try increasing it to 2000, etc.
If the serial monitor program is still running (which it is, if it’s asking you which port to monitor), when you press the ‘Serial Monitor’ toolbar option, you’ll be ask to either terminate (close) or restart the monitor task. This is entirely normal behaviour, and you’ve since found one of ways to properly handle that - i.e. either close it first, or restart it. Another aspect to consider is that only one program can access the serial port at a time, so if one copy of the monitor is running, even if you could run a second copy at the same time, the serial port would be unavailable.
The reopen serial monitor delay does not have any effect on the “Upload and Monitor” action. I set the delay to 5000 (5 seconds), and it launched miniterm.py right after the upload finished. It definitely did not wait 5 seconds. (Note that I did not have a monitor process already running.)
If I do
platformio run -t upload; platformio run -t monitor
it takes enough time to launch platformio the second time that the serial port has reappeared, and the serial monitor connects. Unfortunately, it misses the initial output from my program (which I could work around by adding a delay at the start of my program).
To be expected if you don’t have a monitor process already running, since it’s a reopen delay, and it didn’t need to delay before reopening!
And yeah, you’ll need to add a delay to your program start, if the underlying issue is a delay in the OS enumerating the device. To add the delay on platformIOs side, this would probably work for the upload and monitor tasks, since it adds the delay after the upload has finished…
