Forum Replies Created
-
Posts
-
Hi,
The easiest way to get it working would be to use exactly the same CMake command line that is used by VisualGDB. You can export it into a batch file (together with the relevant environment) as shown here.
Hi,
Different GCC versions use slightly different optimization logic, so it’s fairly common for a GCC update to trigger previously dormant bugs in the code.
You can try using the new Live Tracing functionality in VisualGDB 6.0 – it can record various function calls on both old and new versions of the firmware into trace files, where you can compare them side-by-side. It won’t directly show the root cause, but it will point to the moment in time when the behavior starts being different.
Hi,
Please let us know the email address associated with your license key so that we could check your support status.
Hi,
All we can see from this error message is that a legacy project (non-MSBuild and non-Advanced-CMake) did not build.
Normally, the errors window or the build log should contain other error messages that should explain what is going on.
Hi,
In our environment, the Raspberry Pi just automatically picked up the date via NTP, so no adjustment was necessary.
If the time sync doesn’t work for you, we would advise investigating and fixing it first. Changing target system time during builds could cause much more problems than it would solve, so we would not advise doing that.
Hi,
If it is a generic Eclipse project (not STM32CubeIDE), VisualGDB won’t be able to import it automatically. Instead, we would advise using the generic import mode of the Embedded Project Wizard to pull all the project sources into a new Visual Studio project. Then, you would need to manually transfer the build settings (list of include directories, preprocessor macros, and device-specific flags).
When importing the project, you can select “specify flags manually” on the MCU selection page (see this tutorial) and later use the first page of VisualGDB Project Properties to specify the device-specific settings. If you use Advanced CMake, you can later export the custom BSP into a reusable package and use it to create new projects easier.
With J-Link, VisualGDB caches the device list in the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.segger-dmsp\DeviceList.txt file. You can either delete it to have VisualGDB re-query the device list, or just patch it manually. You can also bypass it completely and edit the J-Link command line manually via the Advanced view in the VisualGDB Settings.
Hi,
Please try updating to the latest VisualGDB 6.0 Beta 2. If the problem persists, please let us know.
Hi,
VisualGDB supports 2 types of custom build steps:
- First of all, you can add custom build steps by editing the build files of the underlying build system (e.g. Makefiles for GNU Make or CMakeLists.txt for CMake). The exact way to do it depends on the underlying build system (Make, CMake, MSBuild, Arduino, etc).
- You can also use the VisualGDB GUI to add custom pre-build/post-build actions. I.e. VisualGDB will execute arbitrary command lines, transfer files, etc. before or after build. These are defined globally (not per-file) and can be configured via VisualGDB Project Properties -> Custom Build Steps. This feature requires the Custom edition or higher, so if you are using a lower edition, you can upgrade it here.
Hi,
Such behavior is usually configured via the sdkconfig parameters. VisualGDB provides a GUI for editing them on the first page of VisualGDB Project Properties, although the exact settings are defined by the ESP-IDF and do not come from VisualGDB.
If you need help locating a specific sdkconfig setting, feel free to ask on the Espressif forums. If you can confirm that the setting works when edited manually but is not working with the VisualGDB GUI, feel free to let us know and we will investigate.
Hi,
It could be related to paths or missing libraries on the target. You can use the View->Other Windows->VisualGDB Diagnostics Console window to see the exact gdbserver command line used by VisualGDB (e.g. cd <directory> && gdbserver <…>).
Then, try running it remotely via SSH from another machine:
ssh <username>@<deployment machine> <gdbserver command line>
If you get a similar error, please double-check that the executable is compatible with the target and included in the PATH.
Hi,
VisualGDB tries to use gdbserver if the project is built on one machine and deployed to another one. You can double-check it on the first page of VisualGDB Project Properties.
Sorry, works just fine on our side, after removing references to the headers you didn’t attach.
Such issues are practically always caused by something very subtle in some very rare place (e.g. a specific overridden #define or edited file) and are impossible to troubleshoot without pulling them apart as we described earlier.
Hi,
Sorry for the delay. We have investigated this and it turns out NRFConnect 2.4+ requires a newer version of Python (we tested 3.11.5 and it worked). However, older NRFConnect versions, and some other frameworks used by VisualGDB are not compatible with Python 3.11 and require older versions (3.8 works).
We have updated VisualGDB to keep separate track of several Python installations and pick them based on the project type and the SDK version.
Please try installing this build [VisualGDB-6.0.2.4929.msi] and updating the package catalog via Tools->VisualGDB->Manage VisualGDB Packages->Online. It should fetch the correct package definitions and pick the correct Python package compatible with the NRFConnect version you are using.
Hi,
We are not aware of any known problems that would cause this. A good starting point would be to try reproducing the problem on a clean project created from scratch. If you can reproduce it there, please share the repro steps that we could follow in order to reproduce the problem on our side.
If not, please try comparing the broken project files against the working one – the difference is likely caused by some setting or something particular about the project structure.
Hi,
OK, we have investigated the issue with MSBuild projects. Turns out, it was a combination of the Visual Studio bug we reported in May, and a change in the STM32IDE project structure, that referenced the headers in a different way, that interfered with one of the workarounds used for older projects.
We have fixed it in this build: VisualGDB-6.0.2.4922.msi
With CMake, VisualGDB would normally group the source files by their physical paths, hence the source/header filters would indeed be linked to each other. If you wish, you can disable the splitting into sources/headers entirely, or disable grouping by paths and group by virtual folders instead (similar to MSBuild). See this page for more details.
In general, CMake projects support multiple targets (applications/libraries) within the same project. If you are importing a large external library with a non-trivial folder structure, we would advise putting it into a separate static library (see this tutorial). It will appear under a separate node in Solution Explorer (side-by-side with the application node, but within the CMake project node). If you have multiple such libraries, you can organize them arbitrarily by creating virtual target folders (target grouping is separate from source file grouping, so you can group targets by their function, and keep path-based grouping for files).
The best of organizing the code this way is that the library-specific settings will be stored in the library’s CMakeLists.txt file, separate from the rest of the project. E.g. if the library has some public include directories and expects certain preprocessor macros, you will only need to specify it once, and can then reference that library from any other embedded project, and VisualGDB will automatically combine the project-level settings (e.g. target device) with library-level settings (which sources to build and which include directories to use).
