Forum Replies Created
-
Posts
-
Hi,
The VisualGDB Android support focuses on a few very advanced scenarios needed by our enterprise users (such as unit tests, management of complex CMake-based repositories and development of low-level Android utilities). If you are new to Android and are just looking for an easy way to get a basic app working, there is no advantage of using C++ over Java, hence VisualGDB does not aim to support this scenario. Please consider using native Java-based tools instead.
Hi,
You can use the Memory Explorer window to get a detailed report on the RAM/FLASH usage by various parts of your program and then replace some of them with less memory-intense alternatives.
Hi,
Unfortunately, it’s hard to suggest anything specific based on the description you provided. Most likely, some of the project settings contains an invalid path somewhere.
If the problem occurs consistently, please share the steps to reproduce it per our problem reporting guidelines and we will look further into it.
Based on our best knowledge, the ESP8266 GDB stub is not compatible with the v3.x SDK. You can try cloning the gdb stub project explicitly and add its source files to the project. If the stub doesn’t work, please double-check with Espressif whether there is a gdb stub version compatible with the SDK version you are using.
Hi,
Both VisualGDB and STM32CubeIDE perform debugging using the open-source OpenOCD tool. OpenOCD is normally started by passing it a few initialization scripts that configure it. Once it is initialized, it begins listening for incoming connections from GDB.
If you encounter different behavior with VisualGDB vs. STM32CubeIDE, most likely, OpenOCD is launched with different parameters/scripts. If this is the case, please try extracting the OpenOCD command lines from both VisualGDB and STM32CubeMX and try running them manually. If OpenOCD behaves differently, please compare the 2 command lines and try experimenting with them to see what difference is affecting the issue.
If the OpenOCD script used by STM32CubeIDE is different from VisualGDB’s one, we would advise simply copying it to the project directory and manually overriding the OpenOCD command line in VisualGDB Project Properties -> Debug Settings to run it. If the command lines appear identical, please try checking if using the OpenOCD executable from the STM32CubeIDE instead of the VisualGDB-supplied executable changes anything.
Hi,
Thanks for the suggestion. We have updated VisualGDB to combine data from multiple live variables into the same CSV file. Please try this build: VisualGDB-5.5.104.3945.msi
Hi,
No problem, please try this build: VisualGDB-5.5.104.3944.msi
You can now configure VisualGDB to treat assembly files as C files (i.e. pass them to armclang.exe and not remove C/C++-specific flags) by adding the following element inside a relevant PropertyGroup in your .vcxproj file:
<TreatAssemblyFilesAsCFiles>true</TreatAssemblyFilesAsCFiles>
Hi,
According to our records, your support period has expired. We can gladly help you find a workaround, however we would kindly ask you to first renew your support here.
Thanks for confirming it. The issue is likely caused by a recent change in the Visual Studio’s interfaces for the ctrl-click navigation, is already fixed in our IntelliSense engine and will be included in the next major VisualKernel release planned for release in the next 4-6 weeks.
As the issue is minor and has a usable workaround, we will not release a special hotfix for it and would advise using one of the alternative go-to-definition commands until then.
Hi,
No problem. Please let us know if the go-to-definition command works with the F12 shortcut, the “Go to Definition” command in the context menu, or the blue “go” button in the top right of the editor window.
Thanks for letting us know. Unfortunately, it’s hard to suggest anything specific without being able to reproduce the problem on our side. If you could find a specific sequence of steps to reproduce the problem and share it with us (along with the relevant screenshots per our problem reporting guidelines), we will be happy to look into it.
We do have long-term plans for adding a better outline window. For now, please consider right-clicking in the source file and selecting “Explore Source File”. It will open a Tree Browser window showing the structure of the current file with all classes, methods and even variables.
Hi,
This is something managed by the ESP-IDF itself and VisualGDB doesn’t have any special GUI for it. Please consider checking ESP-IDF documentation for more details.
That said, VisualGDB ESP32 projects directly use the ESP-IDF build tools, so once you manually configure secure boot per ESP32 documentation, the rest of the VisualGDB functionality will still work as expected.
OK, we got some additional input from Microsoft and managed to add a workaround for this to the following build: VisualGDB-5.5.104.3941.msi
Hi,
The ESP32 debugging is implemented by the ESP32 OpenOCD port. We have specifically tested it with J-Link Pro and FT2232-based debuggers (e.g. Olimex ARM-USB-OCD-H and also the on-board debug interfaces of the ESP32 development boards).
That said, using J-Link to debug ESP32 devices requires installing the libusb drivers for J-Link instead of the regular J-Link driver (you will need to restore the J-Link driver to use the J-Link Software for ARM devices again). If you do not wish to do it, please consider getting an FT2232-based debug probe.
Thanks for the detailed repro steps. The problem was triggered by the BSP listing its own root directory as one of the include directories, so VisualGDB incorrectly overwrote the converted CMake rules file when copying the include directory contents.
We have fixed the issue in the following build: VisualGDB-5.5.104.3938.msi
Regarding other issues:
- The device display in the wizard is correct. VisualGDB shows all devices supported by the Atmel START framework with the download icon to hint that this device is supported. The specific device you have imported is shown with the lightning icon indicating that it is ready to be used right away.
- We have updated the logic responsible for detecting the main.c file. You should be able to create a project from the default template now, rather than creating an empty one. The rtos_demo_main.c will no longer appear as a part of the imported SDK.
- The SDK you shared did not contain a Makefile, so VisualGDB could not compute all relevant build flags from it. Please make sure you follow step 4 of the Atmel START tutorial so that VisualGDB can compute the precise build flags (such as FPU flags) when importing the SDK.
