Serial monitor issue: Multiple uploads not possible

Development Tools Uploading
1

Hello everyone,

I experience issues uploading and monitoring my Arduino devices. When connecting to the device the port is showing up with the correct IC

image
image656×417 44.9 KB

Now I can connect to the device and also upload a sketch

image
image657×417 46.3 KB

Now the issue: When reopening the monitor or trying to upload the sketch again, the monitor is not responding

image
image656×417 48.7 KB

Same behavior when using VSCode with PlatformIO. One upload is possible, but only one.

UserSideException: Cannot configure port, something went wrong. Original message: PermissionError(13, 'Ein an das System angeschlossenes Gerät funktioniert nicht.', None, 31)

Reconnecting the device(s) allows to upload only once.

Setup:
I have two Nanos with USB-mini connector. Usually I have my original "blue" USB cable from Arduino, but forget them in another lab. Currently I am using a 1m USB-to-USBMini cable from my Lattice FPGA programmer. The only difference in the setup is a different cable.

I tried:

  • Restart
  • Using machine with Ubuntu (currently using Win10)
  • different USB ports on the notebook
  • different ports on the USB-Hub (my main main for uC stuff)
  • different Nanos
  • opening the Arduino IDE as admin

Has anyone experienced something similar?

2

Only one program can communicate with the Arduino at a time. If both the Arduino IDE and the Platform IO programs are running concurrently, only one will have access to the serial port and the other one will be denied access.

3

I tested the IDEs separately. When connecting to an already locked port (multiple monitor tabs or IDEs) I get

UserSideException: could not open port 'com9': PermissionError(13, 'Zugriff verweigert', None, 5)

this usually means that the resource is already locked from another process.

4

So, you have ruled out my first suggestion. My next troubleshooting step would be to try a different USB cable. Perhaps this one is not functioning properly with your nanos.

5

I found 3 cables in our department:

  • Some old grey one with a filter on both ends
  • The connector cable from an USB2.0 Hub
  • The original cable from my Lattice programmer

The lattice cable was my biggest hope: gold contacts, short, stiff and used for programming FPGAs (very data heavy).

The result is the same for all "foreign" cables.

My best guess, that there must be some software "flag" for the cable. Maybe some reset exception is not triggered. With this idea I tried connecting and manually reseting the Nano with the onboard button. No effect.

6

Hi @v3xX. Please tell us which USB to serial bridge chip your Nano board has. This is the largest black chip on the bottom of the board.

The chip will usually be identified by writing on the top. This might say something like "WCH CH340G" or "FTDI FT232RL".

Examples:

WCH CH340

CH340
CH340223×151 63 KB

📷

SparkFun - CC BY-SA 4.0 (cropped)

There are some boards on the market that have a USB chip with the same IC package as the WCH CH340, and which are identified by the computer as a CH340. However, these chips don't have the "WCH CH340C ..." labeling like you see on the chip in the picture above:

unlabeled SOIC-16 IC
unlabeled SOIC-16 IC400×417 71.4 KB

📷

NodeMCU Lua Lol1n V3.jpg by Popolon - CC BY-SA 4.0 (cropped)

These mysterious unlabeled chips have different characteristics than the labeled CH340 chips, so please let us know if yours is labeled or not.

FTDI FT232R

FT232RL
FT232RL1920×1458 131 KB

📷

ICIC-SS28-X-K232-01 by oomlout - CC BY-SA 2.0 (cropped)

If it isn't clear, alternatively you can provide the link to where you bought the board from and we'll see if we can determine the chip from the product listing.

7

I don’t believe that your guess would be possible. USB cables with the mini end for USB 2.0 are simply 4 conductors in a cable with straight through connections. The software will only detect the device on the end of the cable and has no information about the specific cable in use.

8

It is just a guess, since the cables behave the same. There has to be some magic in these Arduino cables.

Both CH340 (via VSCode)

image
image694×218 8.39 KB

EDIT: I cant see the label, since the Nanos are soldered on a PCB with the Atmega side up

9

Please tell us the exact name of the device you see for these ports under the "Ports (COM & LPT)" section of the Windows Device Manager.

10

image
image781×572 28.2 KB

image
image408×455 6.97 KB

image
image408×455 7.61 KB

11

Sorry, I misremembered. Please tell us what you see when you perform this procedure:

  1. Open Windows Device Manager.
  2. Double-click on the serial port of the board in the device tree.
    The "Eigenschaften von USB-SERIAL CH340 (COM9)" dialog will open.
  3. Select the "Details" tab in the dialog.
  4. Select "Bus reported device description" from the "Property" menu.

Now tell us the exact text you see in the "Value" field of the dialog.

12

Sorry, that the menus are in German. Company notebook.

ManufacturerInfo: CH341PORTSA64.dll,SerialPortPropPageProvider
Stack: \Driver\CH341SER_A64 \Driver\USBHUB3
Service: CH341SER_A64

13

I have some success, which makes the situation more confusing.

Current setup:
Notebook <---> USB-to-USBMini-Cable <---> Usb2.0-Hub (with USB-Mini) <---> USB-to-USBMini-Cable (Gold connector) <---> Nano

This setup seem to work. I can upload sketches via VSCode and Arduino IDE multiple times and also open the monitor afterwards. Now there are 2m cables and a HUB between my target and my notebook and it works.

14

No worries. I don't speak the language, but I am able to work around my linguistic deficiencies well enough by using Google Translate.

Unfortunately this doesn't tell me what I was hoping to determine.

What I'm trying to determine is whether the USB chips on your boards are the standard WCH CH340, or a strange variant of that chip sometimes found on the boards sold by some of the more sketchy sellers on the online marketplaces. The latter have been reported to cause the "Port monitor error: command 'open' failed: Invalid serial port. Could not connect to COM13 serial port." error from Serial Monitor, as you are encountering.

Usually we can easily visually identify the dodgy "CH340" chips because they lack the label that is found on the legitimate CH340 chips. Since that is not possible in your case, I was hoping to use an alternative characteristic that was reported here:

https://github.com/SHWotever/FakeCH340DriverFixer#how-to-recognise-a-fake-ch340g-chip-

Most of the counterfeit chips are showing as USB2.0-Ser! instead of USB2.0-Serial from the USB descriptor

For example, if I follow the instructions I provided in my previous reply with a port of a board I have with a legitimate CH340, I see this:

image
image417×464 7.38 KB

This is the first time I have attempted this technique and I don't own one of the boards with a dodgy "CH340", so this is why I have been fumbling around a bit to try to figure out how to do this.

Anyway, I think the best way to proceed is to just assume your boards have the dodgy "CH340":

This error only occurs when using the latest version of the CH340 driver with those chips. For this reason, the workaround for the problem is to perform a "roll back" to an older version of the driver that is compatible with these problematic "CH340" chips. I'll provide instructions you can follow to do that:

  1. Click the following link to download the previous version of the driver from the chip manufacturer's website:
    https://www.wch-ic.com/downloads/file/65.html?time=2023-03-16%2022:57:59
  2. Wait for the download to finish.
  3. Run the downloaded CH341SER.EXE file.
  4. A "User Account Control" dialog may now appear asking "Do you want to allow this app to make changes to your device?". Click the "Yes" button.
  5. A "DriverSetup(X64)" dialog will open. Click the "INSTALL" button in the dialog.
  6. Wait for the driver installation to finish, as indicated by the appearance of a "Driver install success!" dialog.
  7. Click the "OK" button in the "Driver install success!" dialog.
    The dialog will close.
  8. Click the X icon at the top right of the "DriverSetup(X64)" dialog
    The dialog will close.
  9. Close Arduino IDE if it is running.
  10. Connect the Arduino board to your computer with a USB cable.
  11. Open the Windows Device Manager.
  12. Select View > Devices by type from the Device Manager menus.
  13. Open the "View" menu.
  14. If there is a ✓ to the left of the "Show hidden devices" menu item, click on "Show hidden devices" to disable it.
  15. Open the "Ports (COM & LPT)" section of the Device Manager tree.
  16. You should see a port identified as "USB-SERIAL CH340 (COMn)" under the "Ports (COM & LPT)" section (where "COMn" is some serial port e.g., COM4). Double click on that item.
    The "USB-SERIAL CH340 (COMn) Properties" dialog will open.
  17. Select the "Driver" tab of the "USB-SERIAL CH340 (COMn) Properties" dialog.
  18. You will see a "Roll Back Driver" button in the dialog. If it is not clickable, perform the following instructions:
    1. Click the "Update driver" button.
      An "Update Drivers Device - USB-SERIAL CH340 (COMn)" dialog will open.
    2. Click on "Search automatically for drivers" in the "Update Drivers Device - USB-SERIAL CH340 (COMn)" dialog.
    3. You should now see the driver installation wizard update the driver. Wait for the update to finish, as indicated by the message "Windows has successfully updated your drivers" in the dialog.
      :red_exclamation_mark: It is possible you will instead see the message "The best drivers are already installed". If so, please stop following the instructions here and reply on this forum topic to let us know. I'll provide alternative instructions you can follow.
    4. Click the "Close" button in the "Update Drivers Device - USB-SERIAL CH340 (COMn)" dialog.
      The dialog will close.
  19. Click the "Roll Back Driver" button in the "USB-SERIAL CH340 (COMn) Properties" dialog.
    The "Driver Package rollback" dialog will open.
  20. Click the radio button next to "My apps don't work with this driver" in the "Driver Package rollback" dialog .
  21. Click the "Yes" button.
    The "Driver Package rollback" dialog will close.
  22. Click the "Close" button in the "USB-SERIAL CH340 (COMn) Properties" dialog.

Now start Arduino IDE again and repeat whatever you were doing before when you encountered that error before. Hopefully this time everything will work as expected.

15

What an extensive and in depth set of clear instruction. Thank you. I followed them and after a restart I experience following behavior:

  • All three cables work using a USB port of the notebook.
  • All three cables work using my main USB Hub
  • Only the cable with filter does not work with my "programming Hub" (a mobile hub for all my programmers)

Conclusion:

I have a lot of them at home (FTD and CH340, probably sketchy), but never used them in applications of the institute. However, looking at out supplier sites there are multiple variants of the Nano. Only RS sells only the original Arduino. My wife sent me a pic of my original Nanos and Unos from home. It appears I am using "licensed" clones? (They were bought from our electronics shops, not Ali or similar).

With this new settings I may can expand my HUB with more flexible and longer cables to clean up the wire mess in the labs.

@ptillisch, @jeremy97469 Thank you very much for the help and time to debug my issue

16

They are definitely not official Arduino Nano boards because we know that your boards have a CH340 USB chip (regardless of whether or not it is a legitimate WCH product), while the official boards use the FTDI FT232R USB chip.

The Nano is open source hardware, so anyone can make a clone of the board. The thing that would require licensing is if the manufacturer wanted to use the Arduino trademark. The term "clone" is more accurate in the case where the hardware is functionally identical except for branding. In the case of a board that has the fairly significant difference of using a different USB chip, it is probably more appropriate to use the term "derivative".

It is always possible the shop owner bought them from AliExpress, but who knows.

Even though that "FakeCH340DriverFixer" GitHub repository I used as a reference makes the accusation of the unlabeled chips being "counterfeit", and surely the lack of labeling and lack of compatibility with the latest driver versions is suspicious, I haven't actually seen any conclusive evidence that the chips are counterfeits. Other than perhaps someone doing a microscopic analysis of the silicon, I think probably only WCH could tell us exactly what is the deal with those chips.

You are welcome. I'm glad it is working now.

Regards, Per