[support]

Hi,

Thanks for clarifying this. The “$(ProjectDirLinux)6731_OMFV”  path suggestion is definitely wrong. It is likely suggested because VisualGDB checks the variable list before ProjectDirLinux gets assigned (and hence defaults to an empty value). We have added an extra check on our side to avoid suggesting empty variables in paths, although manually replacing the path with /6731_OMV should work.

Either way, we have double-checked the screenshots you provided and found a few inconsistencies:

1. The project path on the Windows machine is n:\6731_omfv\SHMUEL\tdp_develop-linux\tdp\dsc_cmp\projects\rdp.vcxproj. The corresponding project directory on Linux should be /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsc_cmp/projects.
2. The Linux path of bit.cpp you mentioned is /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsg_cmp/src/bit.cpp.
3. The relative path reported by gcc is ../src/bit/bit.cpp. Given the base directory, it should translate to /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsc_cmp/src/bit/bit.cpp, that doesn’t match the path in the previous step.
   
4. The Windows path computed by VisualGDB when you tried navigating to the file was n:\6731_omfv\SHMUEL\tdp_develop-linux_test\tdp\dsg_cmp\src\bit.cpp. The _test part should not be coming from the project settings shown on the screenshot.
   

Our best guess is that you have multiple projects that use slightly different (although confusingly similar) file names, so you are changing the setting for one project, while building a different project. Hence, the settings in the VisualGDB Project Properties do not appear to take effect.

The easiest way to unwind this would be to remove all projects but one from Solution Explorer, get it working for just one project, and then add the rest of the projects back, one half at a time, and verifying that paths still work. Another option would be to to follow the inconsistencies we pointed out (e.g.the extra /bit part and the _test part). They must be coming from some setting in a different project, and searching the project/settings files for these parts might explain what is going on.

[support]

Hi,

No problem, we will clarify.

The variable $(ProjectDirLinux) was created because i understood that Local directory (windows) and Remote directory (Linux) should point to the same directory where the project file is located.
Since i have $(ProjectDir) that defines automatically the project path to windows and i don’t have such variable for Linux, so i had to create $(ProjectDirLinux).

It generally depends on how you created $(ProjectDirLinux). You mentioned environment variable, so we assumed it’s something defined in Windows environment (configured via Control Panel->System Settings), that would be the same for all projects. If you defined it as a custom per-project variable, it should be fine.

You wrote “the contents of its directory will be copied to $(ProjectDirLinux)” i guess you meant the compiler output (such as obj files)

We meant that according to the last screenshot from your previous post, VisualGDB will copy the *.cpp; *.h; *.hpp; <…> files from $(ProjectDir) to $(ProjectDirLinux) for every project that targets MRS-RDP-LINUX. Depending on how ProjectDirLinux is defined, this may work as expected, or may not work at all.

Either way, you mentioned the following paths of the file:

• Windows path: n:\6731_omfv\SHMUEL\tdp_develop-linux\tdp\dsg_cmp\src\bit.cpp
• Linux path: /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsg_cmp/src/bit.cpp

You should be able to get everything working by going to the Path Mappings page of VisualGDB Project Properties for rdp.vcxproj and adding the following mapping:

• Windows path: n:\6731_omfv
• Linux path: /6731_omfv

It should cover all the files inside /6731_omfv. You do not need the entry on the Synchronized Directories page, or any other entry. This entry alone should be sufficient to cover all paths.

[support]

Thanks for your update. We understand that you do not wish to follow our instructions for separating the STM32CubeMX-specific part of the issue from the VisualGDB-specific part. As we have explained before, will not be able to do it for you as a part of our technical support, even if you renew your license. Please consider finding someone else who would agree to help you on your terms.

[support]

Hi,

We do not want to cause any misunderstanding with your renewal and would like to make sure the issue is actually caused by VisualGDB. Please follow the steps from our previous reply and make sure you can find a specific parameter that did not get imported by VisualGDB.

If you cannot narrow this down to a specific parameter, it is likely caused by a bug in STM32CubeMX generator, or one of the libraries you are using, and we will not be able to fix it even if you renew your support.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch. See this page for more information and detailed examples.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.

[support]

Please refer to this page for a detailed explanation of the technical support scope.

Specifically in this case, we can fix it if you are able to:

1. Build the same project using a different IDE (e.g. STM32CubeIDE).
2. Compare the broken project against working project and point out a specific file, or a specific setting that did not get imported by VisualGDB.
3. Confirm that the project file imported by VisualGDB clearly references the file or contains the setting isolated on the previous step (i.e. the issue is with the VisualGDB importer and not the project).

If do not wish to do it and would like us to analyze a non-trivial broken project and find the root cause, we can gladly do it at our consulting rate.

You can find a detailed comparison of different VisualGDB editions here.

 

[support]

Hi,

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey​

[support]

Hi,

In our experience, it is possible with some trial-and-error. We ended up hijacking the configuration command lines for binutils/gcc/gdb, manually patching them to produce a Windows toolchain, manually running them and resolving the issues that arose. If you wish, we can do it for your custom module for a fixed price. We would need your existing VM with the regular toolchain build environment; we will edit it to produce a Win32 toolchain, and will document the steps needed to fix everything. Feel free to reach out to our sales if you would like to get a quote.

[support]

Hi,

Most likely, the project you imported defines something incorrectly. If you would like us to investigate it and pinpoint the root cause, we can gladly do it at our consulting rate.

If you believe it is a VisualGDB issue, please make sure you can reproduce it on a newly project created from scratch per our problem reporting guidelines. If the problem only happens with a specific 3rd-party project, it is likely caused by invalid settings somewhere in that project.

[support]

Hi,

No problem,we have rechecked it. Indeed, Espressif has moved the definition of the CPU-specific settings in a way that VisualGDB couldn’t properly parse. We have updated VisualGDB to handle it properly: VisualGDB-5.6.109.4807.msi​

[support]

Hi,

For ESP-IDF projects, VisualGDB works as a front-end to the regular ESP-IDF build system. I.e. it provides convenient GUI for managing common ESP-IDF settings and tasks, but lets the normal ESP-IDF build scripts handle all the building. E.g. when you add a file to Solution Explorer, VisualGDB would update the idf_component_register() in CMakeLists.txt, but will still let the ESP-IDF handle the actual build, as if you edited the statement manually.

There is no special GUI setting for importing external components made for ESP-IDF 4.4.1 and automatically porting them to work with ESP-IDF 5.0. You would need to manually add them to the project by editing the relevant CMakelists.txt files (see the ESP-IDF documentation for specific instructions), and possibly porting them to the new ESP-IDF 5.0. VisualGDB cannot do this work automatically, but it can make it easier by providing powerful IntelliSense and debugging functionality that will help you navigate the unknown code base faster.

 

[support]

The sdkconfig file contains the values of the parameters, but not their descriptions. The actual descriptions are stored in the KConfig files scattered across the ESP-IDF folder. VisualGDB parses them, combines the result in a convenient searchable tree, fills it with values from sdkconfig and displays it on the first page of VisualGDB Project Properties.

Different ESP-IDF versions can have slightly different setting layouts (e.g. a the same setting could be called differently) and VisualGDB Project Properties would reflect it.

We can double-check the CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ setting on ESP-IDF 5 if you could share a screenshot of your Help->About VisualGDB window to make sure we are looking at the same thing.

[support]

If the inner VS instance crashes without reporting anything to the outer one, you have likely selected an incorrect debug engine when attaching the outer VS instance to it.

Please try selecting both “Native” and “Managed (.Net 4.x)” as the debug engines in the Attach dialog. This should catch crashes caused by both managed and native code.

[support]

Hi,

These settings come directly from the ESP-IDF framework (you can verify this by running the menuconfig command manually as described here). They can differ between different devices and different ESP-IDF versions. If you need help locating a specific option, the best way would be to search the ESP-IDF documentation, ask on the Espressif forum, or look for ESP-IDF examples that could be using that setting.

[support]

Hi,

This typically happens for complex projects using custom toolchains – some of the implicit macros set by the compiler do not get properly passed to the VisualGDB’s IntelliSense engine, and prevent IntelliSense from finding the relevant function definitions in the headers.

In order to track it down, please follow the steps below:

1. Isolate the problem to a minimal project with just one source file, one function (e.g. void test123() {…}) and as little #include<> directives as possible.
2. Manually the actual definition of the missing method by searching the header files.
3. Try opening that header file in Visual Studio and see if the relevant definition is grayed out. If it is, check for conditional statement (#if <…>) that could be blocking it.
4. If you have found the relevant conditional statement (e.g. #ifdef SOME_FEATURE), you can manually pass it to the IntelliSense engine via VisualGDB Project Properties -> IntelliSense Settings -> Additional CFLAGS (the flag in this example would be -DSOME_FEATURE or -DSOME_FEATURE=123).
5. If the statement is not grayed out, try moving the test() function directly in the header file, as close to the definition as possible. If it works from there, some code after the definition is interfering with IntelliSense. Moving the test123() function to different parts of the header file (or further down the #include<> stack) should help isolate the part causing the problem.

[Author]

Posts