For example, a code like below. It keeps printing to the serial port, fast. If I press Ctrl+C in the serial panel before starting upload, upload works. But if I press the upload button without pressing Ctrl+C, it fails with:
avrdude: ser_open(): can’t open device “\.\COM6”: Access is denied.
My guess is that the IDE fails to get a chance to open the serial port because another instance is keep reading from it. But I cannot find a way to close the previous serial panel. Closing all the panels below did not seem to release the serial. The only way I found is restarting Visual Studio Code.
Is there another way to solve this without restarting VS Code or resetting Arduino physically?
long i = 0;
When you say you’ve closed all the panels, do you mean you’ve checked this dropdown, and either done Ctrl+C for each Monitor task, or hit the trash icon to close them? Hitting the X will only hide the panel, not end that task.
Usually PlatformIO will stop active monitor tasks, build and upload your code, and restart the serial monitor, so I’m not sure what’s happening there. But if it doesn’t close that would explain the problem - as either it’s not closing, or something else is accessing the serial port.
I had clicked the trash can icon repeatedly until all the panels at the bottom were closed, but that did not solve the problem. I think the serial monitor was somehow still running in the background. Is there a way to kill it when its window is not visible?
In the taskmanager, do you see a miniterm.py instance running, or a python.exe process where you see in the arguments that it’s running pio monitor? (you can enable the column “commandline” in the task manager detail view to see the exact invocation.)
What is “taskmanager”? Do you mean the Windows Task Manager? If so, I do not see miniterm.py. Or is there something called taskmanager in VS Code? I could not find such a thing by the command search box or by searching web. How can I access it?
By the way, closing the serial panel when there is a lot of serial output makes the whole VS Code frozen (“not responding”) and I had to kill it and restart it.
I see. I had looked for “miniterm.py” instead of “pio.exe”. Anyways, when the problem happened, killing “pio.exe” solved the problem, and VS Code did not show such message. It showed that message when I killed “pio.exe” whilst the serial output was incoming and I had not initiated a new “Upload” procedure by clicking the “->” button in the status bar.
Upload and run a code that constantly outputs text to serial port.
Open the Serial Monitor.
Without terminating the Serial Monitor, click the “Upload” button again.
Upload fails with the an’t open device COM error.
After that, clicking the “Serial Monitor” seems to try to initiate a new instance of it and fails too, so there is no way to kill the rogue Serial Monitor instance from the previous upload in the background other than terminating the “pio.exe” or restarting VS Code.
How exactly do you open the serial monitor? In an external program that PIO doesn’t see? If you do press the “Monitor” or “Upload and Monitor” button to start an (upload and) monitor action, and then want to upload again, PIO should autoclose its own opened serial monitor.
Double check that the PlatformIO extension setting
Those settings are the same, probably as the default, because I have not modified them manually.
Here is the screen recording. The mouse pointer may be difficult to see, because for some reason, the capturing software does not correctly capture the mouse pointer’s size (which is 2X) and the pointer is small.
In case the link above does not work, here is another.
I have been working on ESP8266 code on both linux and windows the last few days, and have been uploading code whilst the serial monitor is running without issue… it auto-closed, uploaded, and re-opened. Not saying your problem doesn’t exist, just that I’m not seeing that behaviour myself.