Forum Replies Created
-
Posts
-
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.
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.
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.
Thanks, this explains it. Something in the build scripts of a particular nRFConnect target triggers an internal error in a particular CMake version, so it silently crashes and VisualGDB doesn’t recognize it as normal error (since there is no error message). It could be related to this particular CMake version, or to some of our patches.
We would normally update the CMake shipped with VisualGDB in a few months after we are done prototyping a rather large feature planned for the next version. It should port all fixes from the mainline CMake, and is likely to resolve this issues as well.
If switching to the normal CMake until than works for you (or if you can narrow down a specific construct causing this), that should be the easiest way to handle it. If not, we can build a debug version of CMake so that you could capture a minidump and we could patch it, but it could involve several back-and-forth iterations.
It looks like you are still using VisualGDB 6.0R5. Please make sure you install VisualGDB 6.0R6. You can check the installed version via Help->About VisualGDB.
Hi,
It should work just fine. Please make sure you are using an unmodified VisualGDB installer and have a valid license.
Hi,
Unless the API is forced to the deprecated server mode (via Tools->Options->VisualGDB->CMake->API for querying CMake state), VisualGDB will automatically detect the API for each project.
It looks like it does attempt it here:
Restarting CMake in file mode...Normally, the log should show what is happening next (VisualGDB trying to launch it in the file mode and possibly hitting some other error). If there isn’t anything obvious, please try the steps below:
- Make sure it works with new project created from scratch on the same machine using the same CMake/toolchain.
- Make a copy of the configuration log (it will contain similar lines for trying the server mode).
- Get a log for the broken project and try comparing it against the working one. It should easily point out what is different.
If nothing helps, feel free to attach both logs here, and we can recheck.
Hi,
We haven’t specifically tested VisualGDB with wayland. In order to get it working, you would need to first find out how to debug it with normal gdb via SSH. Once that works, we can help you configure VisualGDB to replicate that setup.
Hi,
This could be related to a recently fixed bug. Please try installing the latest VisualGDB 6.0R6 and try re-creating the project from scratch.
Hi,
You can use a checkbox in the very beginning of the wizard that allows placing the generated Visual Studio project in the directory of the original project. You can also choose to automatically rename it to match the original project name.
Hi,
No problem, please refer to the following page: https://visualgdb.com/support/callstack
When I load the Arduino framework as a user in VisualGDB for the first time and when creating an Arduino project, it currently downloads automatically a non-functional Arduino framework. But why?
Because Espressif published it as a stable package ready to download. If you install the Arduino IDE and create your first project on the same day as with VisualGDB, it will download exactly the same versions of all packages.
As I mention you should know which one works.
We do that with regular ESP-IDF. A couple of times a year Espressif releases a new toolchain and a new major ESP-IDF update. We quickly test them together, bundle them as a package and release it as a single tested download.
Arduino is much more decentralized with thousands of libraries, cores and packages, so every single day something new gets released somewhere. It’s a great way to quickly put together some proof-of-concept code out of pieces made by others, but it will always involve some troubleshooting and dealing with broken incompatibilities due to the sheer decentralized nature of it. And based on the feedback we get, people often use it for all kids of exotic devices, forks and drivers we never heard about, so limiting it to a handful of verified packages will simply kill most of the use cases.
If you are not comfortable doing it, please use another platform. The STM32 SDKs are rock solid and are additionally tested on our side before each update.
Good to know it works. Most likely, some VS components got corrupt during the installation process, and repairing the VS installation fixed them.
Hi,
No problem, we have a tutorial just for this case: https://visualgdb.com/tutorials/arm/legacy/
