I tested the WiFiScan  example in the Arduino IDE and it works “out of the box” just fine. However, when I open the sketch in VS2019 with VM I cannot get debugging working. I select Start Debugging, the sketch builds and uploads (I need to press and hold “Boot” while pressing “Reset” on the WSP32 module). Looking at the Serial Port Monitor I do not see any output.

Here is my procedure:

1. Set a breakpoint at the start of "Setup"
2. Press F5 to start and debug
3. Wait until I see the start of the download and then hold Boot on ESP32 while pressing and releasing Reset
4. Observe the download completion and then press Reset on the ESP32
5. Note the breakpoint is not hit.

Log file is attached.
Sid

1. Yes the breakpoint is after Serial.begin
2. Yes the baud rate is 115200
3. Yes the Reset or Delay When Debug Starts is checked
4. I see the following in the MicroDebug Trace Window:

Launching Debugger...
   - Serial debug will start immediately. WiFi (or gdb) debug will start a few seconds or a short time after the remote device connects to the network.
   - Switch on 'vmicro>debugger>full speed' to prevent debugger message throttling. (read the docs)
   - If 'in-break live watch' is disabled, continue an existing paused debug session by sending the character 'c' to the board using the Serial window.
   - If uploading on WiFi but debug is on Serial then it is possible the cpu will be in debug break when OTA upload is attempting connect. If this is the case then sending char 'c' using the serial/debug terminal will force the mcu to continue (like F5).
   - WiFi debug? Wifi debug is not fully supported yet. Use the vMicro>Debugger menu to set an alternative debug port such as Serial (default speed is 115k)
   - To view debug messages without trace messages use the 'message windows' option on the monitor window.
   - Switch off this message and other Tutorial messages using the 'vMicro>General' menu
Program Running 'WiFiScan'
User Experience: The serial debugger was delayed waiting for an incoming line of data. If the Serial.print() command is used between breakpoints, then ensure that a line termnator is sent using .println() or .print("\r\n"). Optionally, use #if defined(VM_DEBUG) to add code that is only active when debugging. (if this is expected then switch this user experience message off in tools>options>visual micro>micro debug)

>>> Also do you need to press the Reset + Boot buttons ...
Yes I do. I am using an ESP32 breakout board not the ESP32 Dev Kit.

Hi, it should work correctly but to help you it would be easier to compare like for like with the Arduino IDE. That will help us prove that normal upload and serial is working correctly.

Please change the tool bar configuration from Debug to Release. That should switch the Serial debugger off unless you have manually enabled it? If you have manually enabled the debugger please switch it off.

With debug off please confirm that upload and using serial works correctly and the same as the arduino ide?

Then we can test that normal serial input/output is working.

Thanks

Great thanks, that is working the same as the Arduino IDE.

Can you please close the solution and create a new test project. It doesn't need much code (see below).

Switch to debug and upload. That should automatically add a test breakpoint to the loop(){} and start debugging.

Does that work?

// the setup function runs once when you press reset or power the board
void setup() {

}

// the loop function runs over and over again until power down or reset
void loop() {

}


 

Okay thanks. 

When sharing the serial debugger with your own code there can be some considerations. Using a different serial port for debugging is an option and cleaner. However, sharing the serial port with serial output from user code is the default setting and the most common use of the debugger. It should work under nearly all conditions.

Before we investigate the actual issue can you try to comment the serial.begin() from your own code. Something in my memory says that some esp32 cores have a bug where the serial fails if serial.begin() is issue twice. the visual micro debugger does add a serial.begin() therefore for this test the one in our code is not needed.

Thanks

Good. I look back at history. This issue crept into an espcore some months ago. It has been reported on their git site by us and others. Which version of the core are you using? 

We havent had time to test if it is fixed yet? If not then we might have to add some form of check for esp32 boards.

If you open the platform explorer and click the board manager tab then expand the esp32 entry you will see which is installed.

It sounds like the latest. In future release we will have to try to zap the 2nd serial begin behind the scenes until they fix it.

I am not sure how a new install resulted in 1.0.6. We normally recommend stable but I tested with the latest RC1 and they have fixed it. It is possble it was also fixed in the stable 2.0

You can expand the esp32 node in board manager, that is where you will see the versions. The "grayed" one is the one that is installed. You can click it to uninstall and click a different version to install. Click the "Rescan" when done or restart the ide.

The version list comes from the authors of the esp32. Their web site or git site will explain what is stable. However looking at the list the 2.0.2 appears to be the latest stable. If the entries are not shown as beta or rc then they are stable.

No, the toolchain versions have no bearing to an arduino ide version but I can understand why you might have thought that

The arduino ide 2 is same as the 1x IDE but does not have any built in libraries or toolchains.

OK, mystery resolved. The URL for the board support packages was not set to the GitHub path. I must have found an old document online and used the wrong URL.

Currently installing 2.0.2

Sid

Good to hear that thanks. 

For information. At the top of the Board Manager tree is a node called "Auto Discovery". That provides a single click to add a new .json url to the list of "IDE locations > board support urls". It can be easier than remembering where to look for json urls.

Yes agreed, the tool windows and dialogs are currently being re-written. They also don't support high res monitors very well.

The driver which is needed is WinUSB (v6.1.7600.16385), and this should be installed on Interface 0 of the debug probe via Zadig.  This should ONLY be done on Interface 0 of the device, as the second interface is the Serial passthrough port.

We will amend the documentation on the below pages to detail the driver version.
https://www.visualmicro.com/page/ESP32-Debugging.aspx
https://www.visualmicro.com/page/DebuggerSupportList.aspx

The full setup process can be seen in the below video:
https://www.youtube.com/watch?v=d6toH-qJbOI