[support]

Please confirm that the same project using the same libraries works with Arduino IDE. If not, it is not a VisualGDB issue and it cannot be fixed by VisualGDB.

[support]

Hi,

Looks like the Arduino package might be broken again. You can try checking with Arduino IDE, just make sure you are using the same package versions. If it is also broken, it won’t work with VisualGDB either. If not, we can help you replicate the build results from Arduino Studio.

[support]

Hi,

You would need to run the built executable directly from the target’s terminal to see its output there. The setting controlling the output only affects the X11 window forwarding; the regular text output from the program always goes to VisualGDB when debugging it with VisualGDB.

The path on the target depends on whether you are building the code directly on target, or using a cross-compiler. The easiest way to find out is to open VisualGDB Project Properties, click the variables hyperlink in the bottom, and check the value of $(DeploymentPath) and $(TargetPath). Depending on your project configuration, one of these will contain the executable’s path on the target.

 

[support]

Hi,

The screenshots don’t show anything definitive, so you can try just running it manually from the same user account and check the output. But, given the timing, most likely, the 30-day trial period has elapsed and VisualGDB is now asking for the license key.

[support]

Hi,

Yes, we recently managed to get it working. Had to manually change an option byte per this thread, and use the STM32CubeProgrammer to load the external memory, but after all the manual configuration, it works now. We’ll publish a detailed tutorial in the next couple of days.

[support]

Hi,

Sorry for the delay, we were working on an updated package for the ARM toolchain.

The “noreturn” warning comes from the way interrupt handlers are defined in the release build. VisualGDB provides default “weak” implementations redirecting to Default_Handler(), while the DefaultHandler() itself is declared as noreturn to save a few bytes on prologue/epilogue. The redirected handlers are not declared as noreturn because some of them will be replaced by the user-provided implementations that do return. This saves a few bytes on optimizing away the default handler, but does produce warnings in the full warning mode.

This logic has been in place for about 10 years, so we are somewhat hesitant to change it, as it may break someone else’s workarounds or fixes. If you can find a good way to suppress the warnings with pragmas, you can submit a pull request modifying this file. If it doesn’t change any functionalities, and just disables particular warnings, we can propagate it to the upcoming BSP versions.

With profiler framework, you can submit a pull request here.

As for overriding the warning level, if you are using MSBuild, you can change it on the file level (select the files in Solution Explorer, open properties and change the build flags for just these files). For Advanced CMake, the BSP/profiler go into separate CMake targets, so you can manually add CMake-level statements to your CMakeLists.txt that would alter the build options for just these targets.

Edit: thanks for the pull request, we have merged it. Just one thing, the new SignExtend() version was introducing an extra conditional branch, that is slower than just series of bitwise instructions, so we reverted it to a modified version of the original one, that should address the warnings.

• This reply was modified 4 months, 2 weeks ago by support. Reason: mentioned pull request

[support]

Hi,

You can find some documentation in the Wiki. But in general, the easiest way to get started would be to fork one of the existing BSP generators or debug package drivers, and use it as a reference to build your own one.

[support]

Hi,

Please refer to the MSBuild documentation on custom targets and properties. This is not specific to VisualGDB and we would advise getting familiar with the topic before doing any low-level customizations.

[support]

Hi,

This is by design. The toolbar always shows solution-level configurations, while the VisualGDB configurations are defined on the project level. Most likely, you somehow ended deleting the solution-level configurations and will need to recreate them via the Configuration Manager. See this page for more details.

[support]

Hi,

The rules for invoking the linker for the MSBuild projects are stored in the %VISUALGDB_DIR%\MSBuild\Targets\link.targets file:

<PropertyGroup Condition="'$(GCCBinaryNameForLinking)' == ''">
  <GCCBinaryNameForLinking>$(GCCBinaryName)</GCCBinaryNameForLinking>
</PropertyGroup>
<PropertyGroup Condition="'$(GXXBinaryNameForLinking)' == ''">
  <GXXBinaryNameForLinking>$(GXXBinaryName)</GXXBinaryNameForLinking>
</PropertyGroup>

<GCCLink 
  Sources="@(Link)" 
  CC="$(GCCBinaryNameForLinking)"
  CXX="$(GXXBinaryNameForLinking)"
  ...
>

Hence, you can redefine the GCCBinaryNameForLinking and GXXBinaryNameForLinking to arbitrary values in a PropertyGroup inside your project, and it will replace the default values.

[support]

Hi,

The advanced tracing currently only works on ARM. It involves dynamically generating code that saves the selected variable values, and this is only supported on ARM now. But you can still use Chronometer on any target that has a cycle counter. You will just need to edit the chronometer definitions to tell VisualGDB how to read it.

[support]

Hi,

The exact location of the setting depends on the project type. It is normally either in VisualGDB Project Properties, or VS-level properties that can be edited by right-clicking on the project in Solution Explorer. You can find more information about various project types here: https://visualgdb.com/documentation/projects/overview/

[support]

Hi,

VisualGDB is designed to work with any GCC-based toolchain that is otherwise usable (i.e. can build code without errors). You can point VisualGDB to it by selecting the import option at the bottom of the toolchain selector.

Same for compiler flags like the C_STANDARD: VisualGDB shows a suggestion list based on the XML files in its own directory, but you can always specify a different value, as long as your toolchain supports it.

Update: we have updated the ARM toolchain package that is automatically installed by VisualGDB to the latest release from ARM (14.2). You can install it via VisualGDB Package Manager.

• This reply was modified 5 months, 1 week ago by support. Reason: Mentioned updated package

[support]

Hi,

Sorry about that. It looks like an issue with the 8-bit STM8 device family. These devices are not as popular as 32-bit devices (e.g. STM32) so we do not retest them that often. We will try to address it in one of the upcoming maintenance releases.

If anyone else runs into the same issue, please feel free to check in here, and we will raise the priority of the issue.

As a quick workaround, you can try copying the PreprocessLinkerScript option definition from $(VISUALGDB_DIR)\MSBuild\PropertyPages\gcc\linker.xml  to MSBuild\PropertyPages\cxstm8\linker.xml, but it many not solve all the issues with STM8.

[support]

Sure, you can set Tools->Options->VisualGDB->CMake->Use pre-built CMake for Local Builds to false, and then change VisualGDB Project Properties -> CMake Build Settings -> CMake Command.

[Author]

Posts