Forum Replies Created
-
Posts
-
Hi,
No problem, you can set the CommonExecutablePath property by manually adding the following lines to the .vcxproj file:
<PropertyGroup> <CommonExecutablePath>[Value]</CommonExecutablePath> </PropertyGroup>Hi,
It’s hard to suggest something specific here because the variable logic is handled by the Visual Studio itself rather than VisualGDB. You can try reproducing the problem on a regular non-VisualGDB project using the Exec task and then contact Microsoft for help.
If the VisualGDB projects behave differently from the regular MSBuild projects, please let us know and we will help you replicate the regular VC++ behavior.
Thanks, we have confirmed that the new module attribute layout is also used in the 5.4 kernel branch after the v5.4.52 release. We have updated the check accordingly. Please try downloading the new installer.
The “no such host is known” error typically means that the machine running GDB cannot resolve the host name of the target. The easiest way to work around it would be to use IP addresses instead of host names in the settings.
If it doesn’t help, please share the screenshot of the error message you get, and any diagnostic logs or traces shown in it, and we will help you resolve it.
We have rechecked it. Please try restarting the target and clearing the /tmp directory if it contained the previous version of LinuxKernelDebugHelper.
If it doesn’t help, please double-check that the SequentialModuleInfo.c file copied to the target contains the USE_NEW_MODULE_ATTRIBUTE_LAYOUT check and that the check is enabled when building on your kernel (e.g. add an #else \\ #error Unexpected ) after the Linux kernel version check.
If it doesn’t help either, please let us know the output of running the “uname -a” command on the target machine.
Hi,
This likely happens because the header file is referenced by one of the source files inside the BSP (i.e. imported from the STM32CubeMX template) and not inside the application itself.
Please try selecting the BSP instead of the application when adding the discovered include directories to the project settings. If adding the directories to BSP doesn’t work, please try this build: VisualGDB-5.6.1.4079.msi
Hi,
No problem, we have reproduced and fixed the issue. Please try updating to VisualKernel 3.1R8 here: https://sysprogs.com/VisualKernel/download/
No problem, please let us know the email address associated with your license key, so that we could check your support status.
Hi,
This would involve manually editing the CMakeLists.txt files created by VisualGDB. You can generally use the if (SIMULATION) syntax to make sure that a certain part of the CMake script will only be relevant to the simulation platform, or vice versa. E.g. you could define different versions of the same library for simulation vs. hardware, or 2 different versions of the statement that references common libraries.
That said, editing the project structure via Solution Explorer will ignore the parts of CMakeLists.txt that are currently inactive, that may lead to build errors later. We can only recommend this for users familiar with CMake semantics that are OK editing the generated scripts manually and troubleshooting possible errors later. If you would like to rely solely on GUI, please try using #ifdef SIMULATION in the code instead.
Sorry, we are currently prioritizing a few other features over it. We will post an update here if we get more concrete plans for releasing an SDK.
Hi,
This looks like an IPv6/IPv4 issue. Please try specifying “127.0.0.1” or instead of localhost, or using the IP address from another network interface.
Hi,
No problem, indeed the header file list from the Pico SDK directories was overriding the header list from the target directory. We have fixed it in the following build: VisualGDB-5.6.1.4074.msi
Hi,
Thanks for pointing out the subdirectories. We have rechecked it and indeed, one of the cases with subdirectories in project samples was not handled correctly. Please try this build: VisualGDB-5.6.1.4074.msi
In order to use the Fast Semihosting and Profiler framework with FreeRTOS, please make sure that the BSP defines the USE_FREERTOS macro and adds the directory containing FreeRTOS.h to the include search path. The easiest working example of it would be the STM32 BSP (search for AdditionalIncludeDirs and AdditionalPreprocessorMacros in the BSP.XML file).
No problem, we have merged the new thread with the old one.
The “multiple definition” error is expected if STM32CubeMX provides its own definitions of the semihosting-related functions that conflict with the toolchain-provided ones. In order to use the implementations enabled via VisualGDB Project Properties, you would need to remove other conflicting implementations from the project, either by patching the STM32CubeMX-generated sources, or by changing the STM32CubeMX configuration.
Hi,
We would advise comparing the sample definitions with the existing BSP (where the examples work). E.g. you can copy a single sample project from the regular BSP, make sure it works, and then modify it, one step at a time, to match the custom example you would like to ship with the BSP. If you verify that the examples work after each step, you can easily find the step that causes the build errors.Hi,
Good to know it works. BTW, we do have a couple of tutorials explaining extern “C” and the generic “undefined reference” error:
