[support]

Hi,

This could be caused by incompatible FLASH settings or if VisualGDB had problems resetting the board. Can you confirm that the basic LEDBlink program shown in the tutorial gets programmed and the LED actually blinks after you restart the board manually?

If yes, what happens if you press the reset button while the debug session is active, try resuming it and then set a breakpoint in the blinking loop?

[support]

Hi,

This could be our bug. Are you able to reproduce this with a basic “Hello, world” project, or does it only happen for a certain big project?

[support]

Hi,

As a part of a workaround to a different VS bug, we have experimented with editing the .vcxproj files directly instead of using the VS APIs. This mechanism seems to work, although it is not 100% stable yet. If you are interested to try it out, we could send you a preliminary build with this feature in the next 1-2 weeks.

[support]

Hi,

The connection looks very similar to what we have (unless the individual pins are confused), so the best advice we could give is to double-check each and every connection with a multimeter (also check for accidental short-circuited wires) or try another NodeMCU board.

This could also be caused by some undocumented ESP8266 functionality disabling the JTAG connection, so erasing the FLASH using the serial bootloader might help as well.

[support]

Hi,

This still looks like a configuration error. Please try manually checking the <project>\build\sdkconfig file for lines like this:

CONFIG_ESPTOOLPY_PORT="/dev/ttyUSB0"
CONFIG_ESPTOOLPY_BAUD_115200B=y

Do the port name and baud rate mentioned there make sense? If yes, please try flashing the ESP32 in verbose mode:

make flash V=1

This should show the command line of esptool.py. Does the port path shown there match the port path shown in the sdkconfig file?

 

[support]

Hi,

Looks like you are missing some source files or libraries. Please try searching the ESP-IDF tree for .c and .a files containing the ‘emac_send_pause_zero_frame_enable' text and then try adding them to your project.

[support]

Hi,

Please double-check the serial port name you have specified in the project settings (see step 6 of the tutorial). Most likely it does not match the actual COM port number used by the device.

[support]

Hi,

This looks like a JTAG wiring problem. Please double-check the JTAG pins you are using and ensure you have no other hardware connected to them.

[support]

Hi,

This depends on the exact type of error you get. Could you paste the entire log from “test OpenOCD settings” here?

[support]

Hi,

The “Error: JTAG scan chain interrogation failed: all zeroes” suggests a wiring error. Please double-check the JTAG wiring you are using and ensure the JTAG pins are not connected to any other external components. If you are using a different version of the NodeMCU module than shown in our tutorial, please double-check its schematics that the pin numbers have not changed.

[support]

Hi,

Yes, we will support this out-of-the-box once the ESP32 gdb stub supports full debugging (so VisualGDB will be able to provide complete debugging experience without JTAG).

[support]

Hi,

This is a known issue. The automation interfaces used by Visual Studio do not support specifying paths like $(LOCALAPPDATA), so VisualGDB has to hardcode the path in the project file. Normally if you open the file on a different machine with a different user name, VisualGDB should automatically adjust the references (this may sometimes not work if the project and the $(LOCALAPPDATA) directory are located under the same drive letter).

[support]

Hi,

You can do this via Help->About VisualGDB.

[support]

Hi,

We have released an updated OpenOCD build. You can install it via Tools->Manage VisualGDB Packages.

[support]

Hi,

Normally VisualGDB should use the $(LOCALAPPDATA) syntax in the Makefile. If not, can you confirm that you are using the latest VisualGDB 5.2r9?

[Author]

Posts