Forum Replies Created
-
Posts
-
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/
Good to know it works. If you encounter any further issues, please feel free to create another thread.
This error looks like you are using some special characters or variables in the linker script path and VisualGDB fails to resolve them (it would need to resolve the linker path in order to insert the memory definitions in it). We have added more detailed error message for this error in the following build: VisualGDB-5.4.110.3230.msi
Hi,
No problem. The file name case for breakpoint setting comes from Visual Studio itself and would normally match the actual case of the path. Please try right-clicking on the tab header for the file in the VS editor and select “Copy Full Path”. Then check if the path seen by VS has the correct case. If yes, please double-check that you have not accidentally specified incorrect case via VisualGDB Project Properties -> Path Mapping.
If the path shown by VS doesn’t match the actual case of the file, it could have been cached somewhere on the VS level. Normally deleting the .vs directory and reopening the project should solve this (please ensure you are not specifying incorrect case via VS command line or anywhere in the VS project creation GUI).
If this doesn’t help, please let us know and we will provide further diagnostic instructions.
No problem. We have managed to reproduce the problem. It was not caused by using the older apt-get syntax (it is still fully supported and VisualKernel keeps it for backward compatibility with older distros), but was instead caused by a change in the versioning tag format of the kernel symbols for recent Ubuntu builds (the symbol file version is 25.26~18.04.1 instead of just 25.26). We have updated the version matching rules in the following build: VisualKernel-3.1.0.2230.msi
Thanks for the detailed description. We have pinpointed the problem and fixed it in this build: VisualGDB-5.4.110.3228.msi
Sorry, our regular product license only includes email and forum support. If you are interested in screen sharing support, please contact our sales to get a quote.
Based on the description you provided, gdb (the low-level debugger that is a part of the toolchain) fails to evaluate the variable shown on the screenshot. This could be caused by a bug in gdb or some configuration issues. We would advise enabling gdb logging as shown on this page and confirming that gdb never replies to the -var-create command. If this is the case, please try using a different version of gdb, or avoid evaluating the variable that triggers the gdb bug.
Hi,
Please try referencing the Fast Semihosting framework on the Embedded Frameworks page of VisualGDB Project Properties.
We have just updated our semihosting tutorial to show it on the latest VisualGDB version.
Hi,
This looks like another instance of this issue. Please follow the instructions in another thread to obtain another diagnostic log and we should be able to fix it.
