Forum Replies Created
-
Posts
-
Hi,
The hardware ARM tracing requires more pins than just traceclk/traceswo. Generally, the J-Trace documentation should explain all the necessary wiring and you can verify that it is working with the Segger Studio.
For VisualGDB integration, you can check this tutorial: https://visualgdb.com/tutorials/arm/tracing/traceback/
Good to know it works.
VisualGDB’s Arduino subsystem is specifically designed to replicate the original Arduino build process. It plugs into the Arduino builder to extract the compiler flags into IntelliSense, but otherwise it uses the same paths, same tools, and same build rules to produce exactly the same build result as the original IDE (but with much better GUI, IntelliSense and debugger integration).
If you had to manually specify a particular package list URL in Arduino IDE, it could have installed different (patched?) versions of the packages compared to what VisualGDB installed. You could have achieved the same result by changing the board URL in VisualGDB’s Arduino settings. Either way, it’s fairly typical for Arduino ecosystem to have multiple slightly different versions of packages that need some manual installation/configuration. But once you get it working to the point where Arduino IDE works, VisualGDB will pick up your configuration and will produce the same results as well.
Edit: we have double-checked that package lists and it turned out VisualGDB was using an older package list URL and installing slightly older package versions (that we previously tested on our side). It is hard to say why they would cause random errors instead of just working as they used to earlier, but we have updated the package list URL on our side to match the latest URL from Espressif. Now the packages installed by VisualGDB should 100% match the ones you installed manually.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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/
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.
