[support]

Hi,

Please try changing any settings on the Embedded Frameworks page to resolve the debugger_check problem.

In order to fix the REL32 problem, we would need to be able to reproduce the issue on our side (please check the function located at the address shown in the error and see if you can share the source code for that function or a simplified version of it that still reproduces the problem).

The last error looks like you are trying to validate stack usage without actually specifying the stack size. Please reference the “fixed stack/heap” framework to set the stack and heap sizes explicitly.

[support]

Hi,

Great to hear you found VisualGDB useful. There are indeed several ways to build VisualGDB projects on the build server without installing VisualGDB there.

Once way would be to create a CMake-based or Makefile-based project. For these type of projects the build is managed by the external Makefile (or CMakeLists.txt file) and hence they can be built by running Make/CMake manually.

If you would like to use MSBuild, please check the .rsp files generated in the build directory on your Windows machine. Each RSP file contains the exact command line used by VisualGDB to compile or link that file (VisualGDB would simply run <gcc executable> @<relative path to the RSP file> from the main source directory). You could then create a very basic script that will enumerate the rsp files and reconstruct the build script for the build server (you will need to replace the paths in the .rsp files via some basic pattern matching though).

Let us know if you have further questions and we will be happy to help.

[support]

Hi,

Thanks for reporting this. We have fixed it in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2784.msi

[support]

Hi,

Thanks for reporting this. We will investigate it and will release an updated BSP in the next week.

[support]

Hi,

You should be able to work around this by adding the directory with the ULP toolchain to the global system PATH or MinGW2’s .profile/.bashrc. Alternatively, please try this build and add the relative path of the directory with the ULP toolchain to the AdditionalPathDirs element inside toolchain.xml. VisualGDB will automatically add it to PATH when running the ESP-IDF tools.

[support]

Hi,

Sorry, not yet. It is still queued for investigation and we will probably get a more specific timeframe for it in the next 2-3 months.

[support]

Thanks for the update. Not sure what you meant about private and public-scope source files. CMake libraries typically have private and public header search paths and properties, but there should be just one list of source files. If you believe this is caused by some specific layout of your libraries, could you try reproducing it on a clean CMake project and send it to us? If we could reproduce the problem on our side, we should be able to fix it (or suggest a workaround).

If not, please use this build. It will show the path to the CodeModel.json file in View->Output->Advanced VisualGDB Projects Output (search the window contents for CodeModel.json).

The jumps inside Solution Explorer are handled by the VS itself. Visual Studio 2017 does not switch the active file automatically and provides a button for doing that instead. If this doesn’t work, please attach a screenshot of the entire VS window showing the problem (please don’t attach cropped screenshots – they hide the state of many common controls, project load status, etc. and generally make it nearly impossible to understand what is going on).

No worries about the editor. We have edited your post fixing the formatting.

[support]

Hi,

uVision 5 shows every possible FLASH memory because it comes with pre-built FLASH programming plugins for those memories. VisualGDB uses a different approach – instead of providing ready plugins for all common FLASH memories (that would considerably raise the VisualGDB license price due to the overhead of maintaining them), it offers a FLASH driver plugin interface that lets you create a plugin for the device you want to use. We also offer paid service of creating FLASH plugins on demand (please contact our sales if you would like to get a quote).

We are aware of the text scaling issues. The “Additional Memories” page is one of the last property pages that was not switched to the newer WPF technology (that is 100% compatible with high-DPI displays) and hence may appear distorted. We should be able to fix it in the next major VisualGDB release.

[support]

Thanks for sharing this!

[support]

Hi,

Do you mean the path where VisualGDB deploys the executable? If yes, please use the “deployment path” setting on the Debug Settings page of VisualGDB Project Properties.

[support]

Hi,

Please follow the instructions from Espressif on configuring the toolchain for ULP projects.

[support]

Hi,

The red cross in front of the header file means that it does not participate in build. This is expected for header files – they are never compiled directly and are always analyzed in the context of a source file (.cpp) including it. Please try reproducing the original problem with the missing headers when including them from a source file, not another header file. If it can only be reproduced when including files from headers, please ensure that the header file triggering the problem is actually included from one of the sources (otherwise VisualGDB will try to guess the compiler flags for it based on the most commonly used flags and it may not be accurate for multi-target CMake projects).

The CodeModel.json file should be located in the following path:

<Directory of the main CMakeLists.txt file>\<Binary Directory from VisualGDB Project Properties>

If your project was imported from a different directory, please search the subdirectories of that directory for the CodeModel.json file instead of the directory of the VisualGDB project itself.

The double header problem could be caused by enabling the automatic header location inside the target directories. Please double-check the “VisualGDB Project Properties -> CMake Project Setings -> Automatically find header files” setting. It needs to be set to “Disabled” if your headers are explicitly specified via CMakeLists.txt files.

[support]

Hi,

Thanks for the detailed description. Just FYI: the latest version of the GoogleTest package is 20190124-1.8.1, not 20181002-1.8.1. It might resolve some of the issues.

Please also check that the TFS machine has the latest VisualGDB version installed (you might have deployed an earlier version of VisualGDB there manually and have not updated it). You can check the build number via File Properties on the VisualGDB.exe file.

If updating doesn’t help, please confirm whether you are getting the coverage files when running VisualGDB.exe /runtests from your main machine (not from the TFS machine). If not, please try adding “/v” to the VisualGDB’s command line and share the updated output. Please also check if the coverage files are created on the deployment machine in the directory specified via VS Project Properties -> Instrumentation -> Coverage Report Directory. If not, please double-check that the directory is writable.

VisualGDB indeed uses the gcov from its own directory, however it should not cause any problems as the processing it performs is platform-independent.

[support]

Hi,

Sorry about that. It was indeed a bug on our side triggered by a switch to the MinGW2-based environment. We have fixed it and released an updated R17 toolchain.

[support]

Good to know it works. If you would like to find out why the I2C frequency setting affects debugging, please consider creating a thread on the ST forum – someone from the ST community might have an insight into this.

[Author]

Posts