[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?

[support]

Hi,

Yes, but only if you are using Visual Studio to build the projects and both projects are included in the .sln file and selected for build.

BTW, if you are planning to do remote builds, the VisualGDB MSBuild backend actually generates temporary Makefiles (this reduces latency compared to running each compiler instance separately from the Windows side), so you can copy them manually to your Linux target and build them without VisualGDB as well. This only applies for remotely build projects though.

[support]

Hi,

The .bin file produced by MSBuild won’t be helpful, however you can use the esptool.py tool to program the ELF file (usually same name as the .bin file and no extension). To get the exact esptool.py arguments for programming the file, please try programming any project built with the command-line ESP-IDF tools and check the build/programming log.

[support]

Hi,

No problem, we will make an experimental build of OpenOCD based on the latest upstream sources and will post a link here in the next 24 hours.

[support]

Hi,

We are currently in the last stages of the new CMake project subsystem and are experimenting with accessing the Linux filesystem directly, so you can open the remote projects without keeping a separate Windows checkout of the sources. We will most likely release a public preview next week.

[support]

Hi,

Yes, you can use the regular project dependencies/references window in Visual Studio.

BTW, is there any special reason why you cannot use MSBuild? It provides most of the functionality that GNU Make does.

[support]

Hi,

Sorry, this is not supported for GNU Make. You can try hacking the Makefile at your own risk to achieve that, but we generally recommend switching to MSBuild as it provides a straight-forward way for defining per-file arguments.

[support]

Hi,

We usually update the BSPs quarterly, so the next update will be released within the next 1-2 months.

[support]

Hi,

Thanks for confirming this, we will note down that TUMPA is compatible with ESP32.

Regarding single-core mode, you can actually try editing the <SysGCC>\esp32\esp32-bsp\OpenOCD\share\openocd\scripts\target\esp32.cfg file (uncomment the set ESP32_ONLYCPU 1 line), although we have not fully tested this mode and it may result in strange bugs.

[support]

Hi,

Please ensure you are using the MSBuild subsystem (not GNU Make). Then you can use the regular VS properties for individual files or groups of files to edit various settings.

[Author]

Posts