Forum Replies Created
-
Posts
-
Hi,
Most likely the problem is caused by some configuration change on your side and is not related to the update.
Please try narrowing down the problem to a specific sequence of steps that doesn’t work (see the 3-step reporting guidelines here) and we should be able to help you get it to work.
Hi,
This looks like a rendering issue that was introduced by a recent Windows 10/VS2019 update. Please try updating VisualGDB to the latest 5.4R11, as it includes a workaround for this.
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.
