-
|
After successfully uploading laserline from PIO to my M5 StickC Plus I felt a hurdle had been jumped. deja vu This is probably what drove me away from PIO this last time, as it just never happens with the Arduino IDE. I'd like to add that:
Who can help me understand what is going on and how to keep it from reoccurring? |
Beta Was this translation helpful? Give feedback.
Replies: 8 comments 7 replies
-
|
I'm sorry to hear about your continuing COMx problems. Particularly this development after it seemed to be working an hour before must have been very disappointing. I remember having a conversation on these forums with someone, who may very well have been you, in which I indicated that debugging this sort of problem is very difficult without having access to the actual setup in which it occurs. The path between the M5 and what you're seeing includes a whole heap of hardware and software layers, certainly on the Windows platform (Dave actually made a somewhat tongue-in-cheek video about a variation of this some time ago, but I digress). In principle, any of them can balk, causing the whole thing to fall apart in the end. Personally, I've been using PIO with M5 and other devices on Windows and multiple machines (laptops) for as long as I've been involved with this project, and I've never seen the problem(s) you are seeing. Which is great for me and not very useful to you. The only difference between your setup and mine I can immediately see is that your PIO setup etc. is on a different drive than C:. I fully agree that it shouldn't matter, but it's what I see. As I now understand it, you've seen this problem on multiple machines as well now? In that case my primary suspect would be the M5 (it is the device that "owns" the COM port), even though I've worked with multiple of those without running into this. |
Beta Was this translation helpful? Give feedback.
-
|
Could it be that Windows is returning the wrong (or at least an unhelpful)
error message and is confusing "port doesn't exist" (ENOFILE) and "port is
busy" (EBUSY)?
I've seen interactive PlatformIO do this because it launches a monitor
process that holds the port open but when you build and run again, it flips
out because someone (that very monitor process that it created just a
moment ago) is still holding the port?
If so, solution: close all monitor processes before attempting to upload
code. This is a common pitfall amongst PlatformIO users.
At least one user was bitten by another form of this that may be relevant:
zip to the last entry for the punchline.
https://community.platformio.org/t/resource-busy-dev-cu-usbserial-210292ad33e90/23973/16
It may be that Rutger has reached the level of zen that he doesn't launch
monitors because he doesn't debug via printf, perhaps preferring the telnet
interface, which DOES correctly close when the board resets. Maybe he's
reached the zen that he doesn't need monitors at all! :-)
Just recently, I read that upload and monitor used different forms of
autodetect.
…On Thu, Jan 16, 2025 at 3:16 AM Rutger van Bergen ***@***.***> wrote:
I'm sorry to hear about your continuing COMx problems. Particularly this
development after it seemed to be working an hour before must have been
very disappointing.
I remember having a conversation on these forums with someone, who may
very well have been you, in which I indicated that debugging this sort of
problem is very difficult without having access to the actual setup in
which it occurs. The path between the M5 and what you're seeing includes a
whole heap of hardware and software layers, certainly on the Windows
platform (Dave actually made a somewhat tongue-in-cheek video
<https://youtu.be/Gf-dwrwVcMs> about a variation of this some time ago,
but I digress). In principle, any of them can balk, causing the whole thing
to fall apart in the end.
Personally, I've been using PIO with M5 and other devices on Windows and
multiple machines (laptops) for as long as I've been involved with this
project, and I've never seen the problem(s) you are seeing. Which is great
for me and not very useful to you. The only difference between your setup
and mine I can immediately see is that your PIO setup etc. is on a
different drive than C:. I fully agree that it shouldn't matter, but it's
what I see.
As I now understand it, you've seen this problem on multiple machines as
well now? In that case my primary suspect would be the M5 (it is the device
that "owns" the COM port), even though I've worked with multiple of those
without running into this.
—
Reply to this email directly, view it on GitHub
<#678 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD35CXUN5PQ5XLNV6PC32K52FZAVCNFSM6AAAAABVIQE5EWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOBVGI2TCNA>
.
You are receiving this because you are subscribed to this thread.Message
ID:
<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/678/comments/11852514
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
@robertlipe It may well be that you just made the most helpful comment in this discussion... I did run into that particular problem in the past, quickly figured out what was going on and have since then embedded my awareness of this into my workflow to the point I'm no longer casually aware of it. @airnocker If you use the in-VSC PIO monitor at all, this is certainly something to consider. |
Beta Was this translation helpful? Give feedback.
-
|
I did some more looking into this, and if the problem is caused by the COM port being there but being in use, this tool may be helpful towards figuring out what process is responsible, and how: https://learn.microsoft.com/en-gb/sysinternals/downloads/portmon It's part of the SysInternals toolset as published by Microsoft themselves, so personally I'd consider it to be as safe as a tool can be. |
Beta Was this translation helpful? Give feedback.
-
|
Much appreciated @robertlipe and @rbergen! I'll check it out @robertlipe link reference and portmon this evening along with learning more about how and where to find the VSC-PIO monitor. It will be a few hours before I can jump on this and add feedback |
Beta Was this translation helpful? Give feedback.
-
|
Just spent the last hour responding to both of your comments and lost it all when I clicked on the "punchline" comment above. So, I'll start there. My PlatformIO folder is and always has been in my C: users folder. My external USB is what I use a my primary data storage, all apps run from C:. When I became frustrated with the COMs issue in 2023, I copied the NightDriverStrip-main folder to my external USB where I have a folder organized form various MCU code. Recently when I repurposed the VSC for the PIO extension, installed Node.js after learning it was a new requirement, I opened the historical PlatformIO.ini from that external USB folder and it seemed to compile but for the COMs unavailable error. After numerous attempts, I deleted the contents of the NDS-main folder and downloaded the latest copy from Dave's github location. Same results happened, but once, after removing the M5 from Windows Devices and Printers and plugging back in, numerous times, and clicking on Auto and manually picking the PIO's detected COM3 M5, and/or setting back to Auto...it compiled without error and uploaded successfully. With everything still in place after the upload, making two changes to strip width and ring size in globals.h follwed by an F1, it compiled without error but got the unavailable COM3 error like this:
This evening I copied the NightDriverStrip-main folder back to C:\users(myname)...same exact result. I found the PIO-SerialMonitor icon in the toolbar but it doesn't do anything once I open it...and goes away when I compile. No doubt, it is stupid me. I installed the portmon, but it won't allow me to select a port to monitor because the port menu item is grayed out. No doubt, it is stupid me. All this said, I would really like to learn how to use the PIO-Serial Monitor if it would help in showing what and when is using Coms ports. (Also, I read about using the PIO's debug mode but don't yet comprehend how to enable it prior to an F1.) |
Beta Was this translation helpful? Give feedback.
-
|
So now, I just tried this: Interesting to learn about Windows Process Explorer but it didn't tell me whose keeping COM3 open, in use. |
Beta Was this translation helpful? Give feedback.
-
|
Doing a Process Explorer search under the Handle or DLL substring category for USB VID:PID=0403:6001, or COM3, turns up nothing with the VSC-PIO still open having failed the upload of my recent post above. Is this significant? Searching for VCP turns up lots of things shown here:
|
Beta Was this translation helpful? Give feedback.
-
|
Using Windows Process Explorer was a very worthwhile time investment I had not previously known about. By going through the "Find" Handle or DLL process searching all of the recommended items I mentioned above, told me that nothing was interfering with COM3 as far as Windows was concerned. From everyone's input on this and my other related thread it lead me to consider...drum roll please...closing Malwarebytes, which I've had running all along. (I can hear the loud boo's and hisses) THAT WAS THE PROBLEM ALL ALONG! PROBLEM SOLVED, ONE AND DONE!! I'm ashamed of myself. The reward is the journey and the learning experience. Thank you again, @rbergen and @robertlipe for your patience and support. A new PIO journey begins. |
Beta Was this translation helpful? Give feedback.
-
|
That's great news! In the support space I'm happy to yield the majority of credits to @robertlipe for the "not there may mean in use" insight. That put me on the track of finding tooling to look into that. That's a really annoying oversight by the Malwarebytes team. I understand open handles are of interest to software like that, but as you've discovered, peeking into a COM port basically kills it for everyone else. Anyway, good find and happy PIO-ing! |
Beta Was this translation helpful? Give feedback.
-
|
Indeed, nice find. Thanks, but I decline the credit since I ultimately sent
the poster in the wrong direction. Oops!
It's extra annoying that you're paying extra for a program to make another
program you're paying for not run arbitrary programs, which is its literal
job, and that program is making additional work for all of us. (I'm really
bitter about the amount of productivity lost to defective antivirus in this
world since it really shouldn't be anywhere near as invasive as it is.)
With the benefit of hindsight, this unfortunately seems to be a moderately
known thing for at least five years, though the symptoms change a bit:
On the nose:
Jan 2022
<https://forums.malwarebytes.com/topic/282576-esptool_py-from-the-esp32-arduino-toolset-being-blocked/>:
"*MalwareBytes* is blocking the esptool.exe executable that uploads code to
ESP32 microcontrollers over a COM port."
Jan 2022:
<https://randomnerdtutorials.com/esp32-cam-troubleshooting-guide/#comment-717827>
"could
not open port ‘COM5’:... *MalwareBytes* Antimalware was interfering when
esptool tried to open the COM port."
Jan 2022:
<https://community.sparkfun.com/t/esp32-thing-cannot-connect-reliably-to-download-code/42213/3>
"
*MalwareBytes* Antimalware was interfering when esptool tried to open the
COM port."
Jan 2022 <https://stackoverflow.com/a/70633983>: "*MalwareBytes*
Antimalware was interfering with opening the port. I disabled MBAM
Ransomware Protection, and all was well."
Oct <espressif/esptool#682>2021:
"'COM5': PermissionError(13, 'Access is denied.... *Malwarebytes* might
have been interfering with the program."
Duly noting that at least two of these are "yorrick", but there is a post
from MB support that they fixed the problem. Grr.
Related:
Feb 2020:
<https://community.platformio.org/t/platformio-build-fails/11988/29> "I fixed
it. The build went through and finished compiling with success!! it was the
Malwarebytes software."
March 2022:
<https://forums.malwarebytes.com/topic/284844-malwarebytes-preventing-visual-studio-code-from-loading-platformioexe/>
"I have to disable *Malwarebytes* to use Visual Studio Code."
This is just scanning the first page of the search; once you know to
include those terms, there are many, many hits and many more posts that
don't quite come to that conclusion outright but likely have related causes
since the rest of us don't have our own conspiring against us to make us
nutty.
Glad you found it. Now you can get back to bossing around your blinkies and
not battling your tools. I'm off to shop for some super-cool suspenders.
[image: image.png]
…On Fri, Jan 17, 2025 at 2:51 AM Rutger van Bergen ***@***.***> wrote:
That's great news! In the support space I'm happy to yield the majority of
credits to @robertlipe <https://github.com/robertlipe> for the "not there
may mean in use" insight. That put me on the track of finding tooling to
look into that.
That's a really annoying oversight by the Malwarebytes team. I understand
open handles are of interest to software like that, but as you've
discovered, peeking into a COM port basically kills it for everyone else.
Anyway, good find and happy PIO-ing!
—
Reply to this email directly, view it on GitHub
<#678 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD35HY3DYA247F4JTHLD2LDACDAVCNFSM6AAAAABVIQE5EWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOBWGQZTCNA>
.
You are receiving this because you were mentioned.Message ID:
<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/678/comments/11864314
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
Wow. @robertlipe, thanks for finding all those reference links to this very issue, handcuffed directly to Malwarebytes esptool interference or should I say hijacking. I did some searches on this discussion platform and was surprised to find that I had quite a few posts from 2023 that I had completely forgotten about, at least one pointed to another issue I had between the PIO and Malwarebytes. Might it be a good idea to add a warning in the NightDriverStrip-main README.md, "WARNING: Malwarebytes COM ports making them lame!" |
Beta Was this translation helpful? Give feedback.
-
I think that in a more generalized sense that is a good idea. I'll chew on the phrasing a bit and add a section to the README once I've figured it out. Thanks for the suggestion! |
Beta Was this translation helpful? Give feedback.
-
|
I opened #680 to incorporate this. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you. |
Beta Was this translation helpful? Give feedback.
Using Windows Process Explorer was a very worthwhile time investment I had not previously known about. By going through the "Find" Handle or DLL process searching all of the recommended items I mentioned above, told me that nothing was interfering with COM3 as far as Windows was concerned. From everyone's input on this and my other related thread it lead me to consider...drum roll please...closing Malwarebytes, which I've had running all along. (I can hear the loud boo's and hisses)
THAT WAS THE PROBLEM ALL ALONG! PROBLEM SOLVED, ONE AND DONE!! I'm ashamed of myself.
I've done a number of consecutive compiles and all were successful.
The reward is the journey and the learning experience.
T…