Forum Replies Created
-
Posts
-
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,
Good to know it works. If you encounter any other issues, feel free to start another thread.
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:
1<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.
Hi,
This should normally work. If you believe VisualGDB is not working as expected, please try reproducing the problem on a freshly created solution, and provide detailed steps so that we could reproduce it on our side. The steps should include ALL screenshots of ALL wizard steps and settings dialogs, and also the output from OpenOCD window shown when you start a debugging session. This should help us investigate the issue on our side and suggest a workaround.
Sorry, our support only covers our paid products such as VisualGDB. We will eventually release an updated stand-alone version of USBDriverTool, however we are not able to guarantee any timelines for it.
Edit: we have updated the stand-alone USBDriverTool to use the new timestamp server.
-
This reply was modified 2 weeks, 2 days ago by
support. Reason: updated USBDriverTool
Hi,
This behavior should not be different in VisualGDB 5.5R4. Please try checking the GDB Session window for messages explaining this behavior. If nothing helps, please try obtaining and attaching a gdb log as shown here.
No problem, please share a screenshot of the Help->About VisualGDB window so that we could see what is going on.
