ESP32 Forum

Folks,
I'm having trouble programming a devkit c v4 (and another board) using a virtualbox running Linux Mint (latest version) guest on a Windows 10 host.

I added the user to the dialout group.

I captured the "Silicon Labs CP2012N USB to UART bridge controller" usb driver to the virtualbox. The corresponding device then disappears from Windows device manager as expected. When attempting programming, the red activity light on the usb icon at the bottom of the virtualbox window flashes.

There is another driver in the list that seems associated with the same hardware: "Cygnal Integrated Products Inc, CP210x UART bridge/myavr mySmartUSB light [0100]" that I can't seem to capture.

make flash runs and I get the dots and underscores, then "timed out waiting for packet header".

Connecting using putty on the guest at 115200 works and shows the normal ESP32 boot message.

I also tried with a different design of target board with an FTDI adapter. This had the same result (no connection), and via the status lights I could see activity on both the transmit and receive lines when programming was being attempted (and no lights when programming was not going on). Putty worked with this setup also.

Also tried slower speeds, but no change.

The same hardware in the same ports work fine when directly programming from Windows 10 after closing the virtualbox.

Any suggestions?

Thanks

So I discovered that holding down the boot button fixes the problem in this configuration (linux VM on Windows). This isn't required for running natively in Windows.

Is this an inherent limitation of running in the VM?

Hi knotty1,

Glad you found a resolution.

knotty1 wrote: ↑

Mon Mar 18, 2019 9:50 pm

Is this an inherent limitation of running in the VM?

Probably. The timing of the RTS & DTR signal transitions for the "auto reset" sequence have some timing constraints, but there are a lot of things which can influence this timing. Having additional overhead of virtualization is one of them, and can cause the gap between the transitions to be too long for automatic reset to work correctly. There are a lot of variables (hardware, drivers, host OS, guest OS, python VM) that can all influence the timing.

If your virtualization software supports virtualizing the serial port directly rather than the USB devices (so the VM guest OS sees a serial port not a USB device) then this might change the timing enough to make a difference.

You might also find that adding some additional capacitance on the EN pin helps (DevKitC V4 has a capacitor between EN and GND already, but you can try adding another one - something in the 1uF-10uF range, perhaps).