[support]

Hi,

Strange, com.visualgdbm.arm-eabi is a toolchain ID, not BSP ID. Could you have accidentally edited the project files manually and confused some settings? Either way, does creating new projects with the toolchain/BSP work?

If yes, could you please compare the ToolchainID tags in the working vs. non-working projects (in .vgdbsettings files as described here)?

[support]

Hi,

Just to double-check, are you checking the “use the advanced CMake Project Subsystem” checkbox? If you are not sure, please try attaching a screenshot of the Solution Explorer in your project and we can check if this looks like the advanced CMake subsystem is active.

[support]

Hi,

This could be caused by some toolchains-specific or connection-specific issues. We can help you troubleshoot this if you could let us know the email associated with your license so that we could verify your support status.

[support]

OK, we have added support for running custom shortcuts in the background to the final release of VisualGDB 5.3.

[support]

OK, we have fixed the issue with uploading imported project contents on the first build in the final release of VisualGDB 5.3.

[support]

OK, we have added this to the final VisualGDB 5.3 release.

If a manually executed command shows “Loaded symbols for” as a part of its output, VisualGDB will automatically re-query the call stack and update the relevant Visual Studio windows.

[support]

Hi,

The “jtag status contains invalid mode value – communication failure” message usually indicates a wiring error. Lowering the JTAG frequency or enabling “connect under reset mode” might help.

If not, please try a different board. Wiring problems are often intermittent and can get triggered semi-randomly.

[support]

Hi,

For ARM devices the best supported JTAG/SWD debugger would be Segger J-Link. It costs more than low-end debuggers, but comes with its own low-level gdb stub that is actively maintained by Segger, tested with many devices and explicitly supported. Low-end debuggers like Olimex ARM-USB-OCD-H with OpenOCD are also quite reliable, although require some additional initial setup for some devices. Most of the issues you observed (like intermittent FLASH programming, random stops, inability to unwind frames, etc.) are specific for ESP8266/ESP32 simply because they have been figured out on ARM 10-20 years ago and Espressif didn’t have a chance to fix them yet.

Specifically for CC3200, debugging is reliable and works out-of-the-box, but programming the external FLASH memory is tricky and requires 3rd-party tools. For CC3220, OpenOCD has not been fully ported yet, so debugging it involves the proprietary TI XDS gdb stub, that is somewhat buggy, although we have customers successfully using it and can help you set it up if you decide to use it as well.

For ESP32 there is no 3rd-party tool ecosystem, so the Espressif OpenOCD port is the only way to debug their devices (ESP8266 also supports debugging over UART using a software gdb stub that runs on top of your software, but it has not been ported to ESP32 yet).

[support]

Hi,

It is hard to say why deleting the toolchain directory did not help before. Most likely some combination of installing different toolchains and VisualGDB versions left some files open and they were not deleted (e.g. if you had some header files open in Visual Studio, they would not be deleted). If you ever encounter this again, please let us know and we will re-investigate.

Regarding the debug issues, looks like your OpenOCD settings specify the target twice. Please try removing the second definition as shown below:

If stable debugging is the primary goal, we would recommend trying out CC3200 or other ARM-based chips. Espressif is doing a great job at offering superb functionality at a very low price, however they achieve this through not relying on the ARM core with a stable and reliable ecosystem of tools, but instead using a less popular Xtensa core and re-creating many tools from scratch. Given how popular their devices are, they will most likely polish all the rough edges relatively fast, however currently many of the ESP8266/ESP32-related tools are unstable.

We try to include workarounds for known issues and offer out-of-the-box setup and intuitive GUI, however resolving low-level communication issues between the 3rd-party tooling and the 3rd-party chip is unfortunately something beyond what we can offer as part of our products, sorry.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

It looks like your trial has expired. In order to keep on receiving technical support please purchase a license. If you have already purchased a license under a different email, please let us know and we will update our records.

[support]

Hi,

Looks like your toolchain installation might have gotten corrupt (mixed old/new headers). Please try deleting it and doing a clean install (VisualGDB 5.3 deletes the old toolchain directory when updating, however VisualGDB 5.2 does not).

The latest toolchain does include the “ftdi/esp32_devkitj_v1.cfg” file. Please ensure that your settings look like shown below:

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Thanks for checking this. We were not aware of it and it looks like something specific to the msp430 gdb and the device you are using. The only side effect of this would be that the ‘step into new instance’  command (or pressing F10 instead of F5) will not work. Other features should not be affected by this.

P.S. You can also disable the breakpoint in ‘main’ by unchecking the checkbox shown below on the Advanced GDB Settings page of VisualGDB Project Properties:

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Sorry for the confusion. The new toolchains based on ESP-IDF 2.0 and later are only compatible with VisualGDB 5.3 (we had to add a few workarounds in order to support the new Cygwin-based build system). VisualGDB 5.2 should not even show those toolchains in the download list, however if you installed them via v5.3 and then downgraded to v5.2, this would cause multiple weird problems.

Using an older toolchain with a new ESP-IDF would not work either as Espressif changed the clock initialization sequence in the new bootloader that causes the old FLASH programming code to hang.

Hence please try updating to VisualGDB 5.3 and the latest ESP32 toolchain and let us know if you still experience any troubles so that we could help you.

[support]

Hi,

Having 2 separate sets of flags would unfortunately overcomplicate the VS property pages for MSBuild projects, so instead we have the same flags, but automatically filter out options like -fno-exceptions and also allow specifying C/C++ standards separately (use the VS project properties for that).

If you are trying to specify some other option that is only supported on C (or C++) files, let us know and we will add it to the VS property pages for MSBuild projects (unless this is something very rarely used in which case you can simply add a custom target to your project for adding those options similar to RemoveIncompatibleCompilerSwitches).

[support]

Hi,

Sorry, unfortunately checking exact configurations against board schematics goes beyond the scope of our technical support, however we can point you to the most likely cause of the problem.

The following line from the error log suggests that the order of scripts and initialization commands might be wrong:

Error: The 'mww' command must be used after 'init'.

Please try starting with the default settings for ESP32 debugging, ensure that you get a different error (e.g. ‘all bits are zero or one’) and then try modifying the ftdi configuration file to specify your layout.

We have also recently received the ESP-WROOM-32 module (not the WROVER board though) and will be publishing a tutorial showing how to program it over JTAG with Olimex ARM-USB-OCD-H in the next few weeks. You could simply wait till we publish that tutorial and use the schematics from it as a reference.

 

[Author]

Posts