Forum Replies Created
-
Posts
-
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/
Hi,
Thanks for sharing this. This is a leftover from the BSP system layout that used the path explicitly (it can still use it now in some cases like manually overridden per-file settings) and this workaround should indeed work just fine.
If anyone else finds the message too annoying, feel free to post here. If it bothers enough users, we can add a better workaround on our side.
The trouble with the Arduino system is that every vendor (original AVR Arduino, ESP32, STM32, etc) ships their own packages. Often, new package versions fix some bugs from the previous versions and introduce some new bugs. Each of them has their own bug tracker, their own Github repository and their own community. So any work we put into resolving these issues will get completely obsoleted when the next package version comes out. Except, then we would get more requests for help, more issues to fix, and it would quickly snowball to the point where none of the work we do actually improves VisualGDB in the long run, and is quickly obsoleted by another update. We tried it before, we really did, and it’s just not viable, sorry.
What we can reliably offer is convenient GUI and deep integration with VS. You can configure existing package paths and not download anything new. You can choose the framework versions to download. You can decide whether to upgrade or not. You can revert to the old version if the new one is not working. We provide the GUI for all of that, but we cannot take over the maintenance work done by the package vendors. If the latest ESP32 Arduino package has broken debugging on Windows due to some missing libraries, it will remain broken until Espressif releases a fix for it.
As for our builder fork, the only modifications we introduced is accurate dumping of all GCC command lines, so VisualGDB can offer best-in-class IntelliSense that is way more accurate than any other IDE that does not have access to the underlying command lines.
As for the other IDEs, if you can confirm that the same functionality (e.g. debugging) works with another IDE on the same machine with the same versions of all libraries/packages, etc., we can help you configure VisualGDB to match that setup. But we will ask you to narrow it down to specific command lines on your own.
No problem, you can always attach to the stuck process to see what is going on inside it. Just make sure the project used for attaching has physically the same executable than the project that is actually running on the device.
