After 2.3.3 "port monitor error" using ESP8266MOD Node MCU

Since updating IDE to 2.3.3, I am no longer able to communicate with the ESP8266MOD Node MCU module. I get the error "Port monitor error: command 'open' failed".
On the other hand, if I use a more recent ESP8266 card, the communication is done without errors.
The GitHub ESP8266 version used is 3.12. The Windows 10 CH340 USB driver is up to date.
The easy and logical solution is to replace the ESP8266 boards with newer ones, but the pin out is different.
Can someone help me to solve this problem?
Thanks,

Not enough info. Did you restat the IDE after installing the IDE, after installing boards URL's, after selecting which boards to configure?
I have never seen that error, so no idea what is happening.
Did you try a generic dev board?

Hi @mdr1. I'm going to ask you to post the full and exact text of the error message you are seeing in Serial Monitor.

I'll provide instructions you can follow to do that:


:exclamation: This procedure is not intended to solve the problem. The purpose is to gather more information.


  1. Perform whatever action is needed to produce the Serial Monitor error.
  2. In addition to being shown in the Serial Monitor view, the error message will be displayed in a notification will appear at the bottom right corner of the Arduino IDE window. Arduino IDE automatically hides the notification after 30 s, so if you don't see it, click the icon that looks like a bell at the bottom right corner of the Arduino window to display all notifications.
  3. Click and drag the mouse pointer over the text in the Serial Monitor error notification until the full text of the message is selected.
  4. Press the Ctrl+C keyboard shortcut (Command+C for macOS users).
    This will copy the selected text to the clipboard.
  5. Open a forum reply here by clicking the "Reply" button.
  6. Press the Ctrl+V keyboard shortcut (Command+V for macOS users).
    This will paste the copied text into the forum reply.
  7. Click the "Reply" button to post the output.

Is that the board on the right in the picture you shared, or are you referring to both of the boards?

Is the board on the left in the picture the "recent ESP8266 card"?

Hi Sir,
However, before writing to you I had done several tests including an update of the CH340 driver. I reinstalled the old driver 2.5.2019 and the problem is solved. The board selected is NodeMCU 1.0 (ESP-12E).
I did the same exercise on 3 PCs with positive results.


There was a Window update that may have corrupted the driver.
So, to conclude, removing and reinstalling the CH340 USB-SERIAL 2.5.2019 driver may be a solution.
Thank you for your availability and sorry for the lack of precision.

Thanks for taking the time to post an update with your solution.

I suspected that the problem was the incompatibility between the modern versions of the WCH CH340 driver and the sketchy unlabeled "CH340" chip on the board on the right in your picture.

I think it was that it updated the driver, rather than corrupting it. A new version 3.9.2024.9 of the driver was released recently and it is reported that this version of the driver is incompatible with the unlabeled "CH340" chips, just like the previous version 3.8.2023.2. The versions prior to 3.8.2023.2 (<=3.7.2022.1) are compatible with those chips so rolling back to an older version of the driver is an effective workaround.

OK, great! Depending on how you reinstalled that version, it is possible that Windows will update the driver back to 3.9.2024.9 at some point, at which time the problem with Serial Monitor will come back. If so, add a reply here to let us know and we'll provide instructions you can follow to perform a "roll back" operation, which will cause the older driver to be used persistently (at least until a new version of the driver is released, which seems to only happen every year or two).

As a note for anyone else reading this, it is not necessary to go all the way back to version 3.5.2019.1 of the driver to work around the problem. The newer version 3.7.2022.1 is also compatible with these problematic chips. But I'm sure version 3.5.2019.1 of the driver will be fine too.

"Unlabelled" is a politically correct word, "Unlabelled CH340G" are guaranteed to be fake.
Those fake chips really hurts the arduino user community, reinstalling an older driver will only work for a few days as you mentioned until windows update decide to reinstall it again. I think the truth should be spread more clearly. I know the original arduino design is using FTDI or atmega16u as an usb to ttl chip, but lot of clones uses this CH340G chip to cut costs (which is fine to me). Where it goes wild is when those "cost cutting chips" are replaced by counterfeit chips so save a few extra cents.

That's the second driver update targetting or breaking fake chips coming from WCH, it won't stop or get fixed (as genuine chips are working as it should) The only decent solution is to get people conscious of Fake chips existence, get a refund for them as much as they can to calm down this counterfeit market.

I didn't use that term to be "politically correct". I used that term to be factual. I of course have my suspicions about the provenance of these chips, but I don't know for certain that they are "fake". If I knew that for certain, then I would describe them as such. What I do know for certain is that they don't have any labeling, so I describe them that way.

Yes, but it is possible to avoid this by performing a "roll back" operation. When you do that, Windows is smart enough to understand that it should not then update the driver back to the version from which you "rolled back". So the workaround is persistent when you use a "roll back". I'm happy to provide instructions for performing that "roll back" procedure if needed.

I agree that the community members who are unfortunate enough to get a board with the unlabeled chip should do that. In my experience, when I report a legitimate problem to the sellers of this type of product on reputable marketplaces like Amazon and eBay, they will simply give you a refund and not even require the return of the board. So it is quite painless to do.

Sirs,
Sorry for the controversy created about the authenticity of the components if I understood your intervention correctly and the time spent responding.
It is better to close this discussion that I opened as I can see with regret.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.