[support]

Hi,

Sorry, the “download remote directory” command indeed only works with the remote Linux targets. To copy a local folder, please add a custom command line action (xcopy /E <source directory> <target directory>).

[support]

Hi,

This is by design. Our clang engine automatically strips the options that were not tested for compatibility when applying the raw flags reported by CMake.

There are a few easy workarounds though:

• You could try adding “-fms-extensions” to the VisualGDB Project Properties -> IntelliSense Settings -> CFLAGS/CXXFLAGS.
• You could also try editing the CppEngineTuningInfo.xml file in the VisualGDB directory (add -fms-extensions to RelevantCFLAGPrefixes) and restarting Visual Studio.

Please be advised, that we have not explicitly tested this flag with our engine, so it might cause unexpected side effects.

[support]

Hi,

Sorry about that, looks like the proper exception trace for this case wasn’t saved correctly. Please try this build and attach the updated trace: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2417.msi

[support]

Hi,

If it works on the other board, the problem might be caused by some a different configuration/revision + a bug in OpenOCD. If OpenOCD doesn’t show any definitive error messages, you could try building it from the sources (our OpenOCD fork contains convenient CMake build scripts and you can get a compatible MinGW toolchain as described here) and stepping through initialization code to see what triggers the error. Generally, though, please be advised that the ESP32 tools are less reliable than the ARM tools and simply switching to the board that works might be an easier solution.

[support]

Hi,

No problem. Let us know if you encounter further issues and we will be happy to help.

[support]

Hi,

Thanks for your input. We have redesigned the Raw Terminal/Arduino Terminal window to support automatic reconnecting, easier editing of settings, graying out previous text instead of clearing it and several other usability features. We have also resolved several issues you reported. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2418.msi

We have also added support for defining reset sequences for Arduino targets. The easiest way to get started with them would be to edit the ArduinoDeviceIDRules.xml file in the VisualGDB directory. Add the <TerminalResetSequence> element under the <Rule> element for the ARM devices (see the ESP32 rule for an example of the TerminalResetSequence syntax) and restart Visual Studio. Next time you open the raw terminal for your Arduino project, it will show the “Reset target” button that will execute the specified script on the COM port. Let us know if you need more details about reset scripting and we will help you get it to work.

With the VS exceptions, unfortunately we were not able to reproduce them on our side, however it looks like they are caused by the recently added VC++ template bar. Please try checking if the issue can be reproduced on a regular VC++ project (not VisualGDB-based), specifically if you try unloading/reloading it via context menu. If this is the case, please feel free to submit a bug report to Microsoft. If not, please let us know if you manage to get a reliable way to reproduce the problem and we will re-investigate it.

Let us know if you have any feedback/further suggestions and we will be happy to make VisualGDB even better.

• This reply was modified 5 years, 8 months ago by support. Reason: Added support for reset sequences

[support]

Hi,

Most likely VisualGDB fails to process some path reported by one of the internal components. Please try downloading VisualGDB 5.4 Preview 4 and then check the View->Other Windows->VisualGDB Diagnostics Console for detailed exception traces. Please let us know the stack trace shown there and we should be able to fix this, or suggest a workaround.

[support]

Hi,

Sorry, our stack validation logic currently only supports ARM devices. The ESP-IDF is being actively developed and is becoming more popular and mainstream, so we do have long-term plans of porting many ARM-specific features to ESP32, however currently the stack/heap validation tools are limited to those provided by the ESP-IDF itself.

[support]

Hi,

The advanced CMake projects are not based on the Visual C++ project type, so the regular Visual C++ IntelliSense won’t work for them, hence VisualGDB does not allow disabling the Clang IntelliSense.

One option would be to create a regular non-advanced CMake project, however it would miss many usability features of the Advanced CMake Project Subsystem.

Please feel free to share the details on the issues you encounter with Clang IntelliSense and we will help you resolve them.

 

[support]

Hi,

Thanks for the log file. We have fixed the first issue in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2413.msi

The second error looks like the test process terminates unexpectedly, breaking the connection. Please try identifying a specific test that causes it and then use the “Debug Tests” instead of “Run Tests” command to try locating the code responsible for closing the process.

[support]

Hi,

This might be caused by your bootloader (or some other part of the program) modifying the FLASH memory after it is programmed.

Either way, VisualGDB uses the regular “load” command (that in turn issues vFlashWrite packets to OpenOCD). If you would like to debug the FLASH programming logic used by VisualGDB, please consider creating a debug build of OpenOCD (our OpenOCD fork includes a convenient CMake-based project wrapper, see this tutorial).

Alteratively, please try runing the “load” command manually and verifying the memory contents just after it is programmed, but before the program got a chance to run.

[support]

Hi,

Most likely your binary is missing some symbols that VisualGDB expects to find inside FreeRTOS-based programs. Please try locating the following file:

<VisualGDB directory>\RTOSProfiles\com.sysprogs.freertos\RTOS.xml

Then find the RequiredSymbols element and check that your program defines all functions mentioned in side it (e.g. using the embedded memory explorer or by viewing the map file).

[support]

Hi,

The FLASH programming logic used by VisualGDB is actually provided by Espressif (either the OpenOCD FLASH programming commands, or the esptool.py). Please check with Espressif regarding possible ways of optimizing either of those methods.

[support]

Hi,

Thanks for attaching the detailed logs. One error shown in the log files is the missing ‘xauth’ executable that would cause problems when running commands that require X11 redirection. Please try disabling X11 support for that host via Tools->VisualGDB->SSH Host Manager.

If this doesn’t help, please try this build and attach an updated log from the Test Output: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2411.msi

 

[support]

Hi,

The red underlines are normally shown when the Clang IntelliSense discovers errors in the code. Please check the Errors pane in Visual Studio for a specific list of errors. They should explain what is causing the problem (e.g. a missing header file, or an incompatible macro definition).

If you are not sure, please attach a screenshot of the entire VS window (showing the Solution Explorer, the source file with the navigation bar and the error pane) so we could check for common known issues.

[Author]

Posts