VisualGDB 5.4 Preview 1 with support for Advanced ESP-IDF

Recently there was an exciting announcement from the clever folks at sysprogs: Support for the Espressif ESP32 is finally coming to VisualGDB!! (specifically the preview Try It Now link)

In some previous posts, I attempted to get ESP32 JTAG debugging working in Visual Studio with the VisualGDB add-in. I later went on to try out the amazing Visual Studio Code JTAG debugging. In the end it was relatively complex and clumsy. I ended up returning to VisualMicro coding in Visual Studio. Why? Well, simply put there are way more open source libraries that follow the "Arduino Style" libraries. I was never able to get them to work in a VisualGDB project. As of last year, it didn't seem to be very high on the priority list, either.

Why my obsession with Visual Studio? Well, for one, I've been programming in this environment since the beta arrived on my desk on a single 3.5" floppy disk. Yes, even before the days of "dot net" when it was just experimental plain ASP on IIS for Windows NT. Today Visual Studio is an amazing development environment for many target platforms. The robust intellisense and auto-complete features are incredibly helpful.

I find it quite surprising that the Arduino IDE has been so successful, despite having no intelllisense, no auto-complete, and even more: no debugging. What the Arduino IDE does well: get code onto embedded hardware easily. 

The tricky thing with embedded code is that to effectively do single step debugging - a JTAG adapter is needed. This is a crazy world of semi-standards between a variety of vendors supporting different micro-controllers. Most vendors target "mainstream" processors: ARM, STM32, Atmel, etc. The thing with Espressif is they use Tensilica processors. I had never even heard of them until the ESP8266 came along. So it was not a surprise that using existing JTAG debuggers with them was such a bumpy road.

Here I have some comments and observations with the preview version of VisualGDB for the ESP32

Bugs in VisualGDB 5.4 Preview 1

Right-click on "Components". Add - New Item.

Add MyComponent:

What happens? Nothing. There's a quick blink, but no folder appears there. Try adding another. Same result. The directories *were* created. Right-click, add existing item:

The directories are there... even drilling down and adding the component.mk does not make them appear in Solution Explorer.

Another issue is when assigning Preprocessor Definitions:

The compiler will not "see" this change until Visual Studio exit and restart. For some external libraries (in my case RadioHead) - this directive is *never* seen.

Next, is attempting to include external libraries (in this case Arduino style; yes I know it is not officially supported, but it should in fact act just like any other library, no?)

This first example should be pretty self-explanatory: despite being listed in the "components" of the project, the #include "pins_arduino.h" in the arduino.h file cannot actually find the file:

Despite also being listed in the "additional include directories:"

The file is definitely there:

I've been unable to compile. So close, with only "missing" files... so close.  :)

VisualGDB Wish List:

1) Include more Windows Environment Variables in the VisualGDB Build variables. In particular the USERPROFILE, in my case:

USERPROFILE=C:\Users\gojimmypi

Why? Well Arduino-style libraries are typically installed in:

($USERPROFILE)\Documents\Arduino

In my case, libraries such as:

($USERPROFILE)\Documents\Arduino\hardware\espressif\esp32
($USERPROFILE)\Documents\Arduino\libraries\Adafruit_GFX_Library
($USERPROFILE)\Documents\Arduino\libraries\RadioHead
($USERPROFILE)\Documents\Arduino\libraries\M5Stack

2) Right-click on source file name should include the ability to rename. In particular to change from blink.c to blink.cpp.  Otherwise I needed to rename from Windows Explorer. Visual Studio did not "see" the change. I even after exit and restart. Curiously double-clicking on the file forces the re-scan, but only *after* exiting from Visual Studio.

Curiously, only after renaming a source file (such as blink.c to blink.cpp) - and double-clicking on it- does the re-scan occur, causing Visual Studio to then also see those new Component directories added above. (the "Reload Project" does not seem to work consistently)

3) Right-click on file names and components should also allow "Delete" (purge from disk) and "Remove" (exclude from project)

I've submitted this all to the sysprogs forum for feedback and support.

My version of Visual Studio for this exercise:

Microsoft Visual Studio Enterprise 2017
Version 15.6.4
VisualStudio.15.Release/15.6.4+27428.2015
Microsoft .NET Framework
Version 4.7.02556

Installed Version: Enterprise

Visual C++ 2017   00369-90250-38212-AA522
Microsoft Visual C++ 2017

* July 2018 edit:

Over the course of time, my Windows 10 drivers were changed, resulting in the dreaded message:

Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
Error: no device found
Error: unable to open ftdi device with vid 0403, pid 6010, description '*', serial '*' at bus location '*'

Zadig to the rescue once again! Change both drivers on Interface 0 and Interface 1 to libusbk.

I am using the config file found in:

C:\sysgcc\esp32\esp32-bsp\OpenOCD\share\openocd\scripts\interface\ftdi\esp32_devkitj_v1.cfg

That specifically looks like this:

#
# Driver for the FT2232H JTAG chip on the Espressif DevkitJ board
#
 

interface ftdi
ftdi_vid_pid 0x0403 0x6010

# interface 1 is the uart
ftdi_channel 0
# just TCK TDI TDO TMS, no reset
ftdi_layout_init 0x0008 0x000b
reset_config none