Forum Replies Created
-
Posts
-
No problem, please find the answers to your questions below:
- It is possible to pad the .bin file with any specified pattern by editing the linker script. Please see this tutorial.
- CRC calculation is not directly supported by VisualGDB yet, however we should be able to add it relatively easily (it would require the Custom Edition though).
- You can manually set stack/heap sizes by reserving the space for it via the linker script and overriding the _sbrk() function (that controls the heap placement). For devices with VisualGDB-generated linker scripts (e.g. STM32) this is supported out-of-the-box by referencing the “Fixed-size stack/heap” framework via VisualGDB Project Properties -> Embedded Frameworks. For other devices, this can be accomplished by editing the linker script manually (see the .reserved_for_stack and .heap sections in the STM32 linker scripts and also the StackAndHeap.c file).
No worries. This feature has been on our radar for a while. We were initially planning to add it later in the v5.5 release cycle together with other smaller MSBuild-related improvements, but as it’s always better to get feedback from real-world projects, we managed to fast-track it when you mentioned it.
Let us know if you have any feedback or other feature suggestions and we will be happy to make VisualGDB better.
Hi,
This is to be expected. VisualGDB relies on various Visual Studio services for displaying the GUI, managing the settings, etc. Hence a corrupt Visual Studio installation could indeed trigger strange errors in those services, interfering with VisualGDB functionality. Repairing both Visual Studio and VisualGDB installation is indeed the recommended way of solving this.
Clang IntelliSense fully supports renaming symbols. Simply right-click on a declaration and select “Rename” to rename it.
VisualGDB also supports C#-style renaming where you can edit the declaration name in-place and use the Quick Actions menu (Ctrl-. keyboard shortcut) to rename all references.
No problem, we have added experimental support for preprocessing linker scripts in MSBuild projects to the following build: VisualGDB-5.5.2.3415.msi
You can enable linker script preprocessing via VS Project Properties -> Linker -> Linker Script. You can use other properties on the same page to define additional preprocessor macros/include directories and to control whether the default C/C++ ones get automatically inherited.
Let us know if you have any feedback on the new feature and we will be happy to make VisualGDB even better.
Thanks for finding this out. We have updated VisualGDB to create the TestMethod element as well (VisualGDB will only set the “name” attribute, as others are not relevant to the VisualGDB test logic). Please try this build: VisualGDB-5.5.2.3414.msi
If it still doesn’t work, please try manually adding other attributes present in the regular .trx file (e.g. codeBase, adapterTypeName) and let us know which combination of them fixes the problem, so that we could update VisualGDB to set them to some dummy values.
Please try updating to the latest preview build of VisualGDB: VisualGDB-5.5.2.3413.msi
The internal structure of the Teensy core has recently changed and may no longer work with the older VisualGDB versions.
Thanks for checking this. It looks like some minor structural differences between the .trx file generated by VisualGDB and the files expected by the Jenkins tools are interfering with the parsing.
Please try the following steps to diagnose it:
- Create a dummy C# unit test with the MSTest framework. Run it with MSTest.exe and obtain a .trx file.
- Update your Jenkins setup to use a fixed .trx file generated in step 1 instead of the one produced by VisualGDB.
- Check if the test results are imported correctly. If not, double-check the Jenkins setup.
- If the .trx file produced by MSTest works, but the one produced by VisualGDB doesn’t, try eliminating the differences between them. E.g. change the test names in one of the .trx files to match the other one and then try adding the elements present in another .trx file until Jenkins starts recognizing it.
Once you determine what part of the .trx file is interfering with Jenkins, please let us know and we will update VisualGDB to generate it in a way expected by the Jenkins tools.
Yes, we have published the tutorial here: https://visualgdb.com/tutorials/profiler/embedded/coverage/
Hi,
Due to privacy reasons, we do not post sensitive license-related information on the forum. Please contact our technical support for all licensing-related issues.
Hi,
As the error message suggests, please try checking the Output window for details. It will show a detailed build log including the lines that were not directly recognized as clickable error messages.
Hi,
It is hard to say why the specific thread would not be recognized without knowing the exact repro steps. If the problem only happens on a specific project/board combination, please try building our RTX plugin from sources and stepping through ReportThreadList() to see why a particular thread is skipped.
Thanks for clarifying this. In that case, indeed QEmu could one of the best bets, although configuring it would be non-trivial.
Generally, Qemu supports the gdb stub mode similar to VWMare, so we would advise the following configuration:
- Forward SSH port from the target to 10022 or any other port and specify “localhost:10022” as the host name in VisualKernel.
- Enable the gdb stub mode in Qemu and use the “custom” mode in VisualKernel, directing it to connect to the specified host/port.
That said, due to low reliability of Qemu, this setup may trigger strange bugs, or not work at all.
