Any way to delay opening serial port monitor?

I am using PlatformIO in VS Code on a Mac to program an Adafruit ItsyBitsy M4. I can build and upload the sketch, but I have to manually enter the serial port each time. It isn’t available as an option, so I have to type it in, and it is the same port that was just used to upload. If I set the monitor_port setting in platformio.ini, then opening the serial port fails to open with the following error:

could not open port '/dev/cu.usbmodem14101': [Errno 2] could not open port /dev/cu.usbmodem14101: [Errno 2] No such file or directory: '/dev/cu.usbmodem14101'

I think there may need to be a delay in opening the port in order to wait for the device to reboot and become available. Is there any way to insert a delay or retry in the process?

Thanks,
Shawn K.

I might have an answer… I was setting VSCode up so I could run the stable and development versions of PlatformIO side by side, and was looking at the documentation for the VSCode plugin since Ivan pointed me to it… and came across this setting…

platformio-ide.reopenSerialMonitorDelay

Go into your VSCode settings …

… and put it in (2 seconds = 2000 milliseconds, or whatever delay you think you need), adding a comma to the end of the line above if needed (only omit it on the last entry) …

image

And let me know how you go?

1 Like

I have a similar issue with an Adafruit Feather nRF52840 Express (which also has built-in USB). I tried setting platformio-ide.reopenSerialMonitorDelay to 5000 (5 seconds). But this doesn’t seem to affect the delay between upload and monitor; miniterm.py launches immediately after the upload completes.

I have the same problem from the command line.

platformio run -t upload -t monitor

fails with

could not open port u'/dev/cu.usbmodem141401': [Errno 2] could not open port /dev/cu.usbmodem141401: [Errno 2] No 

If I do the upload and monitor as separate commands

platformio run -t upload; platformio run -t monitor

it is able to connect, but misses output from early in my program’s execution.

I suspect that the problem involves the nRF52840 (and ATSAMD51 used in the ItsyBitsy M4) having built-in USB support. The microcontroller restarts after upload, causing its USB to stop. The microcontroller would have to restart USB and the host would have to enumerate it again before the device file reappears (and miniterm.py can connect).

PlatformIO, version 4.3.1
macOS 10.15.3 (Catalina)

Bug report with reproducable project and hardware setup description to Issues · platformio/platformio-core · GitHub please, otherwise devs may not see this.

2 Likes

platformio-ide.reopenSerialMonitorDelay doesn’t seem to have any effect, but this solution, together with delay(100) right after setting up the serial port in setup() (to ensure that no output is missed), works reliably enough to not feel too much like a hack:

platformio.ini:

extra_scripts = platformio.py

platformio.py:

Import("env")

# see https://github.com/platformio/platformio-core/issues/3742#issuecomment-1003454439
def wait_for_monitor_port(source, target, env):
    port = env.GetProjectOption("monitor_port")
    if port is None: return

    print(f"Waiting for monitor port {port}...")
    import serial
    while True:
        try:
            serial.Serial(port)
            break
        except:
            pass

env.AddPostAction("upload", wait_for_monitor_port)
1 Like

Having just been locked in battle with this issue, I found that I had to add monitor_port = /dev/ttyACM0 to my platformio.ini, because the Python script fell through on if port is None: return. I also needed to set “Reopen Serial Monitor Delay” to 1000 in the PlatformIO settings, or the upload step would terminate with Hangup. Now “Upload and Monitor” works!

Edit: Ah, but now I get “The task ‘PlatformIO: Upload and monitor’ (teensy40) (MyProject)’ is already active.” on subsequent Upload and Monitor clicks; I have to “Terminate Task” before doing another Upload and Monitor (clicking “Restart Task” also works). Tedious. Is there any way to repeatedly “Upload and Monitor” with just a single click?

It’s not for everyone, but I script the pio run -e WHATEVER && {
sleep 1
pio monitor whatever
}

Increasingly, I just use tio which handles retries automatically. If the device goes away for a second because the USB controller is resetting, tio just picks back up when it’s back.

You might want to find a way to combine tio and and the symbol decoding thingy from esp-idf (or whatever is used on your system) in order for stack traces to display conveniently. That’s just not a combination I’ve needed to script so far. I’m pretty happy with tio for tight development loops, though.