Forum Replies Created
-
Posts
-
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.
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.
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.
Please note that our support is limited to VisualGDB issues only. We can point out the location of various settings, however we cannot guarantee that every project opened with VisualGDB will build correctly, sorry. Our best advice would be to make sure you understand the structure and requirements of the project and can build it outside of VisualGDB first.
We have provided them with an updated build that follows their instructions and still reproduces the problem on December 17th and have not heard from them since then. Please consider contacting Microsoft support directly, or posting on the bug tracking page to speed it up. We have done everything we could on this one (short from designing our own replacement Call Stack window) and the delay is on their side.
As a side note, a 100% working (although annoying) workaround would be to delete the watch expression that triggers the error, and switch back and forth between the threads via Debug->Windows->Threads. This makes the call stack reappear.
