Forum Replies Created
-
Posts
-
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/
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
