Hi,

It probably won't help but until you have a proven system please make sure you are uploading and testing with the tool bar set to "Release" and not "Debug".

That's very strange. It's windows that is killing the connection as if it doesn't like the usb driver. There are a lot of people using the same system and have done for about 8 years but never with this issue.

I just tried an esp32 and my driver/port shows the same as yours but works fine.

In device manager what is the date and version of the CP210 USB to UART bridge?

There us a difference between vm and arduino simply that arduino uses java to access the port but visual micro uses the microsoft c# methods (System.IO).

Great thanks for letting me know

I think it's slightly different but very interesting. The debugger does normally enabled DTR but avoids doing so with esp8266 because it causes the board to go into boorloader mode. For other arduino boards the DTR is the way to force a reset. It's possible that visual micro is attempting to set the DTR for the esp32 which might cause an issue.

Your report shows it is the esp tool that is failing to connect to the board. Therefore the board must be in the wrong mode.

If this is all true then your report suggests that the DTR is ignored in the earlier usb driver. This thread was about the windows 10 usb driver failing on an older version of windows so that why I think it is different.

You can switch off the delayOrDTR option in the visual micro F4 project properties tool window. This would prove the issue either way.

The only other thing might be timing. The new usb driver might need a long delay between allowing esptool.exe port access for upload v's port access via c# serial debugger.

I will try the esp32 myself. Being a new board it has not had much testing yet but do please open new threads with any reports.

Thanks

Thanks for the report and info @vior

More info ....

I have tested the SiliconLabs CP210x usb driver version 10.1.1.1951 on windows 10 and it fails to work with standard Microsoft C#

The driver throws an error suggesting it can only work with a baud rate of 9075

If you create a new windows forms c# project containing button1 and textBox1 then paste in the code below. Change the port from COM8 to your port you will see the problem.

Notice the baudRate iis set to 9075. Anything faster throws an error.

This is a driver issue however the fact that java from the arduino ide reads the port okay is annoying. I will investigate an alternative port reader but what we use is recommended by microsoft and well tried and tested (until recently)

Having said that. The 10.1 version is listed for windows universal and v6.7 listed for all other windows versions such as win10, win8, win7 etc.

https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vc...

using System;
using System.Windows.Forms;

namespace WindowsFormsApp3
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        System.IO.Ports.SerialPort sp;

        private void button1_Click(object sender, EventArgs e)
        {
            sp = new System.IO.Ports.SerialPort("COM8");
            sp.BaudRate = 9075;
            // sp.BaudRate = 115200;
            sp.DtrEnable = false;
            sp.RtsEnable = false;
            sp.DataBits = 8;
            sp.StopBits = System.IO.Ports.StopBits.One;
            sp.Handshake = System.IO.Ports.Handshake.None;
            sp.Parity = System.IO.Ports.Parity.None;
            sp.ReadTimeout = 10;
            try
            {
                sp.Open();
                //sp.BaudRate = 115200;
                while (true)
                {
                    while (sp.BytesToRead > 0)
                    {
                        textBox1.AppendText(sp.ReadExisting());
                        Application.DoEvents();

                    }


                   System.Threading.Thread.Sleep(200);
                }
            }
            catch (Exception ex) {
                textBox1.AppendText(ex.ToString());
                System.Threading.Thread.Sleep(5000);
            }
            Application.Exit();
        }
    }
}