Forum Replies Created
-
Posts
-
Hi,
This syntax comes from gdb itself. You can read more about it here: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Arrays.html
Hi,
This looks like the behavior of the old VisualGDB version that could not reliably distinguish the load/placement addresses of some sections, and had to guess it. Please try updating to the latest VisualGDB 6.0 Beta 3 – it should handle it out-of-the-box.
Hi,
We have built ARM64 versions of the critical platform-specific VisualGDB components (e.g. VisualGDBNativeARM64.dll, libssh2-arm64.dll), so they will work at full speed.
As for the external tools, we will have to wait until the ARM64 support in MinGW becomes mainstream and stable enough, and we see enough users interested in ARM64 builds. Until then, the normal x86 builds will work just fine through the emulator. If you don’t want to wait, you are always welcome to build the tools on your side and replace the VisualGDB-provided binaries – these are open-source tools built with open-source MinGW, so you don’t need any special parts from us to do it.
Hi,
Sorry, we have not encountered anything similar. Please feel free to post on the Raspberry Pi or Qt forums – maybe you can get some pointers there.
Hi,
No problem, you can turn it off by clicking the CodeJumps button (tag icon) in the upper right corner of the text editor.
Hi,
Sorry, it is hard to suggest anything specific without knowing what exactly you have changed. Please try reproducing the problem from scratch and sharing the relevant screenshots that can help us reproduce it on our side. Please also make sure you are using the latest VisualGDB 6.0 Beta 3 and have renewed your support.
Hi,
This looks like an issue between a particular ST-Link and the target. It could be caused by wiring, broken target, or something else. You can try getting it working with STM32CubeIDE first. If it works there and doesn’t work with VisualGDB, we can help you compare the OpenOCD command lines and get it working as well.
Hi,
It is fully supported starting from the 6.0.4 builds (e.g. VisualGDB-6.0.4.5075.msi). We have tested it on the latest Apple M3 Max and it works just fine (that said, getting drivers for some JTAG programmers to work could be tricky).
You can try contacting the device vendor, or your supplier. Maybe, they could have some suggestions.
As far as VisualGDB is concerned, it runs OpenOCD in order to handle the low-level debug functionality. The STM32 support in OpenOCD is developed by ST and generally works very well with genuine ST devices. If it’s not working with a particular device, the issue is somewhere between OpenOCD and that specific device. If you can get OpenOCD working via command line, we can help you configure VisualGDB to use that command line when you start a debug session. If not, it won’t work with VisualGDB either.
Hi,
The ST-Link devices are specifically designed to work with ST microcontrollers only, so it makes sense that they wouldn’t work with APM32. You can try contacting the device vendor- maybe they supply their own version of ST-Link or OpenOCD.
Hi,
No problem, please try this build: VisualGDB-6.0.4.5073.msi
We have added a context menu command for saving the selected register values (including all subregisters):
The CSV file created with this commands contains 3 columns: the register name, raw hex value (regardless of the actual register size) and the formatted value according to the current settings.
Hi,
That’s because the tutorial is for STM32L0 and you are using STM32H7. These are different devices with different OpenOCD scripts that work slightly differently.
If you are not sure which line to edit, you can try asking on the STM32 forums or OpenOCD mailing lists, but VisualGDB cannot figure out the necessary edits automatically.
Hi,
The only change in the settings since the tutorial is that instead of selecting the “manual mode” and editing each script manually, you can now open the “advanced” view and edit the OpenOCD command line directly. The rest of the tutorial should still apply.
Hi,
This looks like your firewall is interfering with the network connection in some way. You can try downloading the toolchains/BSPs manually or adding VisualGDB to the exception list.
If you are normally using a proxy, you can configure it via Tools->Options->VisualGDB->General->Other->Proxy Server.
