[support]

Hi,

Thanks for your feedback. The “build and Flash” issue might be caused by a timing error somewhere in the FLASHing logic. If you could share the output from an unsuccessful FLASHing operation, we might be able to tell more. We could also add a delay setting between the completion of the build and FLASHing.

With samples, thanks for the suggestion. We will consider searching more directories for samples in one of the next VisualGDB versions, although we won’t change this logic now due to our release schedule.

You can change the colors of the Arduino terminal via the corresponding page of VisualGDB Project Properties (you need to enable it first). We have added an option to change the inactive color to this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2427.msi

We have also double-checked the behavior for failed FLASHing, however could not reproduce any problems. Could you please share the internal output from such a session? Perhaps the underlying tool still exits with code 0 despite the error?

With terminal reset sequence, this is specific to your Arduino board. Please check its schematics and Arduino forums/documentation. Most likely there is a sequence of events (e.g. setting/clearing signals like DTR) that lead to a reset. Once you find that sequence, let us know and we can help you configure VisualGDB to use it.

[support]

Hi,

Please try restarting Visual Studio. If it doesn’t help, please let us know how did you import the toolchain (automatic installation via VisualGDB, manual import, copied the XML file, etc.) and whether the toolchain is shown in the VisualGDB Package Manager or the toolchain selector in the wizard.

[support]

Hi,

Please try running the build command shown in the log file manually and check the output for error messages. Most likely your project either contains constructs incompatible with the newer IDF, or some files cached from the previous build are interfering with the build. In the latter case, please try doing a clean build (Build->Rebuild All). This should remove any cached files.

[support]

Hi,

No problem. This message means that the ProfilerRTOS_FreeRTOS.c file from the profiler framework was either not built, or the USE_FREERTOS macro was not set. Please ensure that the file is include in your target’s file list and try adding USE_FREERTOS to the preprocessor macro list.

[support]

Hi,

No problem. The ESP32 register definitions are not 100% precise, as they are computed from parsing the ESP-IDF header files. We have updated the code responsible for parsing them to handle some of the previously missing registers (see the R11 toolchain release here).

However, other registers (e.g. SPI, UART) that use non-trivial rules for computing the base addresses are still not included. As a workaround, please consider editing the <SysGCC>\esp32\esp-bsp\registers.xml file manually or hardcoding the rules for the missing register groups in our header file parser.

[support]

Hi,

Sorry, VisualGDB doesn’t provide any specific tools for STM32 OTA. We would advise checking the ST examples (they can be conveniently selected on the Sample page of the VisualGDB Project Wizard) and incorporating the code/techniques from them into your code.

[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 6 years, 10 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.

 

[Author]

Posts