Forum Replies Created
-
Posts
-
Hi,
VisualGDB uses the regular memory reading API of the underlying debug method in order to read the peripheral register values. Hence, you can easily verify whether this mechanism is working correctly by running the following commands in the GDB Session window:
x/1x 0x<address of a register> monitor mdw <address>
The first command requests the memory contents from the gdb debugger, while the second one is forwarded to OpenOCD (low-level tool for interfacing with the JTAG adapter).
Please let us know if using the commands shown above still results in incorrect values and we will suggest further diagnostic steps.
Hi,
Sorry, in order to troubleshoot a specific project that doesn’t come from us, we would need to charge a consulting fee, as it takes non-trivial time to go through all the settings and source code and find the exact cause of the problem. If you would like to go ahead, please contact our sales to get a quote.
An alternative would be to create a new project from scratch and then move your existing code to it step-by-step, verifying that the additional memory loading works after each step (consider creating a local git repository and checking in the changes after each step to track them better). This would require some time, but should help you find the root cause of the problem on your side.
Hi,
Please try running VisualGDB.exe /about from the same user account you use for Jenkins in order to show the “About VisualGDB” window that allows entering the registration key.
Hi,
It looks like your support period has expired. Please renew it here and we will be happy to help you.
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
