Forum Replies Created
No problem, we have fixed the issue in the following build: VisualGDB-220.127.116.1109.msi
No worries and thanks for the update. If resetting the repository solved the issue, it was likely caused by corrupt VS-level or VisualGDB-level cache (although VisualGDB-level issues are usually visible on the call stack).
Either way, if you weird intermittent behavior again, you can simply try deleting the .vs and .visualgdb subdirectories – it should have the same effect as re-cloning the repository, but you won’t need to do a full rebuild.January 24, 2023 at 11:49 in reply to: VisualGDB 5.6 Clean And Source line Build Fail connection #33753
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:
- 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.
- The Linux path of bit.cpp you mentioned is /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsg_cmp/src/bit.cpp.
- 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.
- 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.January 23, 2023 at 11:15 in reply to: VisualGDB 5.6 Clean And Source line Build Fail connection #33747
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.January 23, 2023 at 10:08 in reply to: The STM32CubeMX Wizard not working for TouchGFX and AzureRTOS #33744
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.January 23, 2023 at 09:46 in reply to: The STM32CubeMX Wizard not working for TouchGFX and AzureRTOS #33742
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.January 22, 2023 at 16:20 in reply to: How to prevent Visual Studio recompiling whole project #33739
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:
- The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
- 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.
- 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.January 22, 2023 at 10:06 in reply to: The STM32CubeMX Wizard not working for TouchGFX and AzureRTOS #33736
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:
- Build the same project using a different IDE (e.g. STM32CubeIDE).
- Compare the broken project against working project and point out a specific file, or a specific setting that did not get imported by VisualGDB.
- 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.January 21, 2023 at 10:09 in reply to: The STM32CubeMX Wizard not working for TouchGFX and AzureRTOS #33734
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
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.
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.
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-18.104.22.16807.msi
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.
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.
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.