[supportKeymaster]

Hi,

Most likely, you have updated the OpenOCD package to the latest version, and it might contain a bug that would be interfering with the CC3220 debugging.

The easiest way to revert it is to try installing an older OpenOCD build as shown on this page.

If it solves the problem, please let us know the exact OpenOCD versions that work and don’t, and also the exact error output you are getting from OpenOCD, and we will look further into it to see if we can fix it on our side.

[supportKeymaster]

We only mentioned the path in step #4 because it was shown on the screenshot. If it’s not relevant anymore, could you please double-check what happens when you try clicking on the message in the VisualGDB Build window? Do you see another error message with the n:\6731_omfv\SHMUEL\tdp_develop-linux\tdp\dsc_cmp\src\bit\bit.cpp path?

If yes, please try using the File->Open command in Visual Studio, and pasting n:\6731_omfv\SHMUEL\tdp_develop-linux\tdp\dsg_cmp\src\bit.cpp there. If the file cannot be opened, please double-check the path and permissions. If the Windows path of the bit.cpp file is different, the path mapping will need to be updated accordingly.

If you get a different  error message, please make sure you expand the details view to see the path, and attach an updated screenshot here.

[supportKeymaster]

Hi,

No problem, we have fixed the issue in the following build:  VisualGDB-5.6.109.4809.msi​

[supportKeymaster]

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.

[supportKeymaster]

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.

[supportKeymaster]

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.

[supportKeymaster]

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.

[supportKeymaster]

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.

[supportKeymaster]

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.

[supportKeymaster]

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.

 

[supportKeymaster]

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​

[supportKeymaster]

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.

[supportKeymaster]

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.

[supportKeymaster]

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​

[supportKeymaster]

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.

 

[Author]

Posts