Forum Replies Created
-
Posts
-
Hi,
For most of the targets (including ESP32), the built-in gdb simulator is not sufficient to run any meaningful code and can only be used to test that gdb can load the image and parse the symbols. Generally, we would advise getting one of the boards supported by VisualGDB (see our ESP32 tutorials).
This is the same issue the “Warn : Cannot identify target as a STM32 family.” error means that OpenOCD does not know the FLASH configuration for this device (i.e. does not support it).
Hi,
Thanks for pointing this out. Indeed our latest STM32 BSP didn’t work with the non-GNU version of C99. We have fixed it and updated the package. Please try reinstalling it via Tools->VisualGDB->Manage VisualGDB Packages (or alternatively change the C standard to C99 with GNU Extensions).
Just wanted to give a quick heads up that if you are looking for community help, please also consider asking on StackOverflow. It has a large developer community, including many STM32 users and some of them might have encountered a similar issue before.
No problem and thanks for your understanding.
Also if you get STM32-specific advice on the ST’s forums and need help mapping it to VisualGDB GUI (e.g. finding the setting for managing include paths, defining preprocessor macros or adding files to the project), feel free to ask us. This is fully covered by our support, although we did our best to make those settings as intuitive as possible.
Sorry, our support covers issues specific to our products. It is not possible for us to provide general programming help/personalized introductions to external libraries, devices and frameworks as a part of our product support, as the cost of such a service would greatly exceed what we charge for our licenses.
No problem, we can help you solve it via our paid consulting services. Please contact our sales to get a quote.
Sorry, this looks like a question about the STM32 library/framework structure, not something specific to VisualGDB. Please consider posting on the STM32 forums to get help on STM32-specific issues.
Hi,
It looks like the directory path is invalid:
C:\Projects\MyProject\Bootloader..\bin\
the correct one should be as follows:
C:\Projects\MyProject\Bootloader\..\bin\
Hi,
It looks like the instead of passing the breakpoint event to the JTAG debugger, the kernel tries handling it directly. This might also be the cause for kgdboe error you encountered before.
Please try adding the following startup command to VisualKernel Project Properties -> Startup Commands -> Before Connecting to Target:
monitor gdb_breakpoint_override hard
This will force OpenOCD to use hardware breakpoints instead of software breakpoints. Depending on the way exception handling is implemented in this kernel port, it may resolve the issue.
No problem, please try this build: VisualGDB-5.5.2.3447.msi
For your reference, VS2017 has been updated multiple times since 2018: https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes
There may be many reasons why VisualGDB is not working on a specific machine (e.g. corrupt installation, broken registry, incompatibility with other packages) and our normal technical support covers troubleshooting them. However, we are only able to offer it to users with active technical support running the latest version of VisualGDB.
Hi,
Thanks for the very detailed problem description. We have investigated the issue and found out that VisualGDB was ignoring the “deploy as root” option for some cases.
We have fixed it in the following build: VisualGDB-5.5.2.3446.msi
Hi,
The error you mentioned happens because the imported SVD file does not define sizes for some registers. We have updated VisualGDB to assume 32-bit registers when the size is not specified: VisualGDB-5.5.2.3446.msi
That said, the file you attached to the second message appears broken (it triggered an error about mismatching <peripherals> tag), so it will not get imported despite the fix.
Thanks for the clarification. It looks like some patches or configuration in the kernel you are using make it incompatible with KGDBoE.
Generally KGDBoE is less reliable than other debug methods as it relies on several assumptions about the network driver implementation that don’t always hold.
If your board has JTAG pins available, using it instead of KGDBoE should result in much more consistent and reliable experience. Let us know if you need help understanding the connectivity issues between gdb and OpenOCD.
