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

 

[support]

Hi,

No problem, we can walk you through pinpointing and resolving this. First of all, please ensure that you are using exactly the same version of msp430.dll and msp430-gdbproxy both in command-line mode and from VisualGDB.

If both versions are the same, most likely the slow behavior is caused by some command-line argument or gdb command. Please try enabling advanced gdb logging via VisualGDB Project Properties -> Advanced GDB Settings. This will create a .log file with all gdb commands issued by VisualGDB as a part of your debug session. Then please try running gdb/gdbproxy manually with the commands shown by VisualGDB and run the same commands (you can skip commands for evaluating sizeof(void *) and other built-in types).

Can you reproduce the slow behavior by running the commands manually? If yes, please try removing some of them to see which of them causes the slowness. If no, what happens if you launch gdbproxy manually and change GDB settings on the Debug Settings page of VisualGDB Project Properties to “manual mode” and explicitly specify the “target remote :<port>” command? If this works faster, some environment variable that is only present when launching from VS might be affecting the msp430.dll behavior.

[support]

Hi,

Currently there is no special way of deleting the folder without using the VS functionality, although it looks like a good idea and we will try to add it in the next version. If you experience different timings with VS IntelliSense and Clang IntelliSense, we might be able to help you find a workaround. Can you confirm that deleting the same files on the same project takes >2x more time with Clang IntelliSense enabled?

[support]

Hi,

Are you using VisualGDB 5.2? The new ESP32 toolchain is only compatible with v5.3 and v5.2 would suggest downgrading back to the last version that is compatible with v5.2.

[support]

Hi,

Thanks for confirming this. Visual Studio only queries the underlying debugger for an expression if it looks like a valid C/C++ identifier, so ‘(‘, and other operators are not automatically queried. We might be able to override this in one of the future VisualGDB versions via installing a special hook, however we would not do this in v5.3 as the same mechanism is used for ctrl+arrow navigation and we want to avoid breaking it.

[support]

Hi,

Sorry for the delay. We will be able to investigate this in more detail next week after releasing v5.3 RC1. The problem happens because TFS is using a different assembly search path than the regular VS and cannot load the VisualGDB assembly.

Our best advice would be to try different TFS settings related to assembly search path (e.g. see this post) to ensure the build agent can locate the VisualGDB assembly.

[Author]

Posts