Forum Replies Created
-
Posts
-
Hi,
Yes, please ensure you are using the latest VisualGDB 5.4R11. This Ctrl-Click support was added to VisualGDB’s Clang IntelliSense fairly recently and older builds of VisualGDB don’t support it.
Good to know the installer works now.
Regarding the Arduino package numbers, indeed the default Arduino package layout would allow having multiple versions of the same package installed. This matches the behavior of the regular Arduino tools and should not cause any problems. If you would like to reclaim the disk space used by the old packages, it is safe to simply delete their folders.
Hi,
This looks like some cached data on your side is incorrect. Please try opening Tools->VisualGDB->Manage VisualGDB Packages->Online to update the package list.
No problem, we can explain what happened.
The linker automatically discards the symbols that are not referenced by any other symbols in the project, starting at the entry point. E.g. if your main file contains functions func1() and func2(), but main() only calls func1(), the body of func2() will be removed from the linked binary in order to save space. However, it the entry point itself is eliminated, every function in the project will be considered unused (unless explicitly marked with special GNU attributes or linker script directives) and hence the linking will produce a nearly empty result.
No problem, we can help you get it to work.
The “Convert to MSBuild” command will import the common parameters (e.g. include directories and macro names) from the Makefiles and copy them to the MSBuild project properties, however it would not pick up custom Makefile rules and other adjustments. This should work for most of the projects, but may indeed require minor manual adjustments to reflect the settings that were not automatically converted.
Based on what you have described, the assembly files did not get the correct item type and hence are being ignored. Please try selecting them in Solution Explorer, right-click and select Properties (for those items) and set the Item Type on the General page to C/C++ compiler. Please also ensure that they are not marked as “Excluded from build”.
If this doesn’t help, please let us know and we will provide more detailed instructions.
Sorry for the confusion. If the physical library name doesn’t include the “lib” prefix, the easiest way to add it to the project would be to simply add it to the Solution Explorer as if it was a source file (Add->Existing Item). This will have the same effect as using the “Additional linker inputs” field, but will make it slightly easier to manage.
Thanks for clarifying this. Normally, VisualGDB should automatically pick up the header and source file locations from the GPDSC file, although in our experiments the STM32CubeMX tool can intermittently omit some of them, depending on the project settings and the tool version.
Based on the behavior you described, the GPDSC file was missing multiple FreeRTOS-related components; in that case it could be easier to add reference to FreeRTOS via VisualGDB Project Properties -> Embedded Frameworks.
Please also feel free to attach the generated project (as long as you are using the latest STM32CubeMX release) so that we could recheck if we could update the VisualGDB to extract the correct FreeRTOS component paths.
It looks like the project requires the BIQ_CM4_GCC library that could not be located in the standard library search paths.
Please try locating the library manually (it should normally be shipped together with the project) and add its directory to the Library Directories field in VisualGDB Project Properties.
You can find out more about library-related settings here: https://visualgdb.com/support/linkerinputs/
Hi,
Most of the additional windows shown by VisualGDB are displayed in the background. I.e. you simply open other windows over them and do not close them, the window layout next time you start a debug session will be exactly as you configured it.
You can disable the “inline GDB output window” completely via Tools->Options->VisualGDB->Common->Debug->Ignore Inline GDB Stub Output.
Thanks for the update, we have reproduced the problem and fixed it in the following build: VisualGDB-5.4.111.3233.msi
Hi,
Please let us know the email associated with your license so that we could check your support status and we will be happy to help you get it to work.
Hi,
This is actually by design. Semihosting works by triggering a breakpoint so that the debugger can stop at it and read the data produced by the target. If no debugger is attached (or you configure it to ignore semihosting calls), the breakpoint will be handled by either the regular debugger logic, or the exception handler in the firmware.
We normally recommend using conditional compilation (#ifdef DEBUG) to remove semihosting-based logging from release builds. If you are using our Advanced Semihosting framework, you can also configure it to suppress the semihosting calls unless a debugger is attached (see the configuration Embedded Frameworks page of VisualGDB Project Properties), however the hardware registers responsible for detecting a debugger are not present on all devices, hence this may not work on some targets.
Hi,
Thank you for your suggestions on making Live Variables better, however it looks like this mostly duplicates existing features. Please see the explanation below.
The live variables work by continuously reading the target’s memory without interrupting the program and are intended for monitoring slowly changing parameters that could be easily written by the software to fixed locations in memory (e.g. counters for certain internal events, object counters, etc). Together with the plotting functionality, this allows monitoring the state of real-time systems without stopping them on a breakpoint (that could disrupt functionality if the system is expected to handle external requests).
In order to keep a track of more complex/dynamically changing structures, such as strings, please consider using semihosting. Simply dump the state of those variables when needed via the printf() function and VisualGDB will display it in the semihosting view. You can also use the live memory mode in the Advanced Memory Window provided by VisualGDB – it uses the same mechanism as Live Variables and allows reading the memory contents of large objects (e.g. string buffers) without stopping the program.
The Live Variable breakpoints are intended to catch slowly changing critical conditions (e.g. some object counter growing beyond the usual value) and are intended to stop the program once the condition is hit, so that you can examine its state and then continue. As the monitored values would typically not change while the program is stopped in the debugger, the live variable breakpoints automatically disengage after the initial hit in order to avoid an infinite loop.
Hi,
It looks like the STM32CubeMX tool did not include some of the headers or include search paths in the generated .gpdsc file, so VisualGDB did not pick it up.
As a workaround, please try locating the cmsis_os.h file manually using VisualGDB’s header discovery feature as shown here: https://visualgdb.com/tutorials/intellisense/headers/
