[support]

Hi,

There is no fully automatic way to move a subset of settings between projects, however VisualGDB stores its settings in straight-forward XML files (and ESP-IDF configuration is stored in sdkconfig files), so you could try making a basic automation tool that will move the settings you need between projects.

You can configure VisualGDB to invoke the custom tool as a custom shortcut (i.e. menu entry under the project context menu).

[support]

Hi,

VisualGDB does support grouping of source files by folders and it is enabled by default for many project types.

If it’s not working, please do provide the steps and screenshots we requested. We will not be able to help you unless you do so because we do not know what you are doing and why it is not working.

[support]

If you would like us to investigate the issue further, please provide the requested information. If you do not wish to provide it, we will not be able to allocate any additional resources to investigating this and will have the issue closed until anyone else confirms it and provides the repro steps.

[support]

There are no implicit requirements that would lead to this message. If you would like our help troubleshooting this, please do provide the requested information.

[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.
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]

Hi,

This would be fairly straight forward for the regular CMake projects, since CMake supports multiple applications/libraries in the same project out-of-the-box. However, the use of ESP-IDF makes things more complicated, since it implicitly expects a project to have one primary application referencing multiple components.

We would advise researching how ESP-IDF internally defines the bootloader targets, since the bootloader is essentially a separate mini-application built within the same project. You might be able to reuse some of that logic to build the application for the FACTORY partition. That said, it might require patching ESP-IDF or might rely on some APIs that will be changed in future versions. It is ultimately something to do at your own risk.

[support]

Hi,

Thanks for pointing this out. The Renesas devices are quite different from other device families supported by VisualGDB. They extensively rely on fairly complex code generation logic (that uses JavaScript in some cases). VisualGDB does not include a JavaScript engine and cannot replicate the original logic with 100% accuracy, however it still supports a reasonable subset of it that can still save time, while requiring occasional manual adjustments.

In this case, the incorrect syntax comes from the following line in the BSP.XML file:

<string>#define BSP_CFG_ROM_REG_BPS0 (~($$config.bsp.fsp.BPS.BPS0$$ 0U))</string>

You can work around it by patching the file as follows:

<string>#define BSP_CFG_ROM_REG_BPS0 (~($$config.bsp.fsp.BPS.BPS0$$))</string>

You can then set BPS0 to 0 via the project properties (or just hardcode 0 in the template instead of $$config.bsp.fsp.BPS.BPS0$$).

We have noted this in our roadmap for the Renesas BSP, and will look further into it when releasing the next BSP version.

[support]

Thanks for the detailed video. Indeed, the logic for automatically stripping the SSH port worked for the Linux projects, but not for the embedded projects (building the project locally while debugging it with a remote stub running on a target with a custom SSH port is an extremely rare scenario).

We have fixed it in the following build: VisualGDB-5.6.108.4714.msi

[support]

Thanks, we have reproduced the issue and fixed it in the following build: VisualGDB-5.6.108.4714.msi

[support]

Hi,

Just wanted to let you know that we have just released VisualKernel 4.0 Beta 2.

It includes the fix for the LinuxKernelDebugHelper build issue you mentioned, has numerous stability improvements and fixes the issue with the module list filter.

Regarding the extra component in the module path (C:\Users\<username>\source\repos\vmware-ubuntu-16.04\vmware-ubuntu-16.04\vmware-ubuntu-16.04\drivers\media\usb\dvb-usb), VisualKernel computes them using the following logic:

1. Locates the kernel release under your kernel release directory (configurable via Tools->VisualKernel->Manage Linux Kernel Symbols).
2. Loads the matching IndexedModules/InTreeKernelModule element in KernelRelease.xml and appends the PathRelativetoKernel value to the directory of the KernelRelease.xml file.

If you consistently get invalid paths, could you please recheck what module paths are stored in KernelRelease.xml? If they contain an extra component, please try patching the file manually, or just re-importing the kernel using the kernel symbol manager. This should get the correct paths stored, so VisualKernel will be able to load them automatically.

 

[support]

The original issue has been resolved a long time ago, so this is likely something different.

Generally, STM32CubeMX sometimes misses some sources or headers when generating project templates. Newer versions of STM32CubeMX often fix such issues, but sometimes introduce new cases.

The best idea to troubleshoot it is to specifically look for header files defining the missing symbols, and then trace it down:

1. Is the header file included via #include<>?
2. If yes, but the header file is not found, does the include search path contain the header file’s directory?
3. Are the definitions conditional to a #define that is not defined?

If you can narrow it down to a specific construct in the generated STM32CubeMX file that was not imported correctly, we should be able to fix the importing logic to handle it properly. If not, please consider editing the sources manually to include the necessary parts.

[support]

We do provide toolchains for the most common targets (Raspberry Pi, STM32MP1) free of charge.

If you believe that Variscite should be sponsoring a toolchain for their target, feel free to contact them and convince them to do so. We are fine either way, as long as someone agrees to cover the research, porting and testing costs.

[support]

Hi,

The embedded toolchains usually need to be individually built for each specific target. The exact steps vary from distribution to distribution, and often involve troubleshooting some unexpected weird issues, so there is no common guidance here. E.g. we recently updated our STM32MP1 toolchain and had to resolve compatibility issues between the yocto-specific gdb patches and the MinGW toolchain, and also encountered a bug that ware interfering with multi-threaded builds.

You can indeed try using a similar toolchain (e.g. Raspberry Pi), but it may trigger further weird issues when you try to use it for complex projects. It really depends on the differences between the platforms and there’s no fully automatic solution here.

We do offer a toolchain building service for custom targets, so if you start running into strange problems that take too much time to solve, feel free to contact our sales for a quote.

[support]

Hi,

Sorry for the confusion, this is actually by design. One of our customers uses a large solution with multiple test projects to cover several hardware platforms. They use the “build” flag in the Configuration Manager to specify which test projects should be built for each platform, so the previous behavior (showing unit tests from all projects, even if they are excluded from build for the current configuration) was showing a lot of irrelevant tests.

As it looked like a very specific and rare scenario, we did not add a separate setting for this behavior.

If your setup relies on the old behavior (i.e. the projects were not excluded from build by mistake), we can gladly add a setting controlling whether to show the tests from the unit test projects that are not built.

Attachments:

You must be logged in to view attached files.

[support]

According to our records, your trial has expired, hence VisualKernel stopped working. If you would like to get technical support, please consider purchasing a license and make sure you use an unmodified VisuaKernel installer. Please note that creating a new email address and a forum account does not automatically grant additional technical support.

[Author]

Posts