Forum Replies Created
-
Posts
-
This should normally work just fine. If this is a big project that is already triggering internal linker errors, it could be that something else about it is producing an unexpected memory layout.
If you could share the ELF file, we can try loading it on our side to see why it’s triggering this error.
With screenshots, there should not be any major changes in the GUI since the documentation page was created. Feel free to attach a screenshot of the mismatching GUI, and we can check.
Hi,
This is possibly happening because the trace buffer variable is not inside a pre-initialized data section (e.g. .data, not .bss). See this page (search for “pre-defined”) for an example.
With GCC, you can try creating a new project using our BSP (not STM32CubeMX or any other external generator). This way the frameworks GUI should work the same way.
Sure, the .vgdbsettings file has a straight-forward XML structure, so it should be trivial to patch it manually. However, the exact XML element to change would be different for different scenarios.
The easiest way to get it right would be to create a similar project using GCC, make a backup of the .vgdbsettings file, change the settings manually, and diff it against the previous version.
Sure, you can try enabling function tracing, setting the FLASH size via settings, and then disabling function tracing. Another option would be to just manually roll back the relocation record option after changing the Dynamic Analysis settings. The debugging settings are stored in the .vgdbsettings/.vgdbcmake files, while the linker flags (like relocation records) are stored in the CMakeLists.txt/.vcxproj files.
Hi,
Sorry about the confusion. The GUI for setting the end-of-FLASH is hidden unless you enable the instrumenting of functions on the Dynamic Analysis page (see attached screenshot).
As for the tracing, the dynamic tracepoints use fairly complex logic to patch the code after it got already compiled, so indeed, they rely on some advanced compiler features. The good news is that we are working on the GUI for managing coded tracepoints, like TRACEPOINT(“value=%d”, ADCState.Value). These won’t require any special compiler features, and will be integrated into the recording/replaying/configuration GUI, so setting and removing them will be as easy as with regular breakpoints. They will first come out as a part of CodeVROOM (our stand-alone IDE compatible with a subset of VisualGDB), so you will be able to try them out, while still using the stable release build of VisualGDB for the rest of the workflows. We can post a link here in a few weeks, if you are interested in trying them out.
Sorry about that. The integration with the regular VC++ IntelliSense is rather complicated. VS simultaneously runs several tasks from different contexts (some from within Visual Studio process, others from MSBuild.exe), and there are many corner cases, one of which was not handled properly.
We have fixed this one in this build: VisualGDB-6.2.0.5626.msi. If it still doesn’t work, please let us know, and we will provide instructions for narrowing it down.
Also, many thanks for the IntelliSense feedback! The reindexing should normally only happen when a commonly used header (e.g. pch file) changes, however in many projects these files change unintentionally when updating build numbers (or are outright generated during build). We are working on an update that will allow detecting and blacklisting such files, and also choose between aggressive indexing and fast token-based search, similar to what VS does. We will also look into the template completion and post an update here in a couple of weeks.
Thanks for the update.
This could be related to the order in which the tasks are loaded. You can try this build [VisualGDB-6.2.0.5625.msi], we added an extra check there.
That said, MSBuild projects with the VS IntelliSense engine is considered a legacy setup, so we won’t be doing major changes there. For new projects, we recommend Advanced CMake.
If you are not using Clang IntelliSense due to particular limitations (e.g. indexing the entire project when navigating to definition), we are working on a few optimizations to that. If you have a particular scenario that is slow, we can look into optimizing it. It also works way faster when running directly on Linux or Mac using our cross-platform CodeVROOM shell (e.g. see this tutorial), as a lot of its performance bottlenecks come from the Windows limitations when dealing with multiple small files.
Hi,
This could happen if the project was manually edited with some custom targets or build rules, overriding the default VisualGDB target order.
The first step to diagnose it would be to create a new project from scratch and check if it works fine. If yes, you would need to analyze the differences between the 2 projects, open them side-by-side, and try narrowing this down to a specific setting or a custom target.
No problem. A good starting point would be to make sure you can build the project from command line outside the Atmel Studio. Once it works, you can select “project built with command-line tools” and specify the command lines there.
Hi,
There will never be an import tutorial that will work exactly one-to-one with a particular project. There simply too many different project layouts, options, etc.
A good starting point would be to understand the project structure, where different parts come from, and how they are related.
If you have questions about a specific setting that is different between the GUI and the tutorials, we can help, but these differences are usually trivial.
Another option would be to keep building the project in Atmel Studio, and use Quick Debug to debug it.
Hi,
No problem, this should be fairly easy to fix. Just to double-check, are you using the same toolchain in all the configurations?
Sure, you can use this page: https://sysprogs.com/splm/mykey
It shows the download link for the last compatible version, and also gives the renewal quotes.
Hi,
Sure. Within Visual Studio, you can use the View->Other Windows->VisualGDB Diagnostic Console.
For command-line builds initiated with VisualGDB.exe, you can set the VISUALGDB_SHOW_DIAGNOSTIC_OUTPUT environment variable to 1.
Hi,
The optimized WSL backend relies on wsl.exe executable to run WSL commands. E.g. “wsl gcc test.c” would normally just run gcc to compile test.c.
This used to be broken several Windows releases ago, where WSL would randomly hang, so VisualGDB used a much more complicated way to launch commands: it would run a special launcher inside WSL, that would accept a connection via TCP, and would forward the output there. However, this was causing problems with some users’ firewall setups or custom IP address configurations.
So, recently we added an option to use wsl.exe directly again, as the previous bugs we encountered with it appeared to be fixed. We are not aware of any issues with command-line builds. It could be another bug in wsl.exe, or something caused by a particular configuration. If you can narrow it down to a particular wsl.exe scenario, we can try adding a workaround on our side. However, it could be a much easier and safer bet to revert to the “heavy” network-based launching mode.
Hi,
We have just tried doing a clean installation: deleted the entire %USERPROFILE%\.pico-sdk folder, restarted Visual Studio and re-installed Pico SDK 2.3.0 using the VisualGDB GUI. It worked.
You can try first deleting the %USERPROFILE\.pico-sdk\.sysprogs directory and restarting VS, and if it doesn’t help – deleting the entire %USERPROFILE%\.pico-sdk, and re-downloading everything. This should replace any corrupt release list files, resolving the NullReference exception.
That said, the 2.3.0 release should appear under the regular list (not “All Github Tags”) if it doesn’t, it could indicate that something else is broken, so deleting the .pico-sdk directory could be necessary.
Edit: we rechecked the fetching logic, and found the most likely cause. Deleting .pico-sdk\.sysprogs and restarting VS should fix everything nicely.
