[support]

Hi,

Thanks for the feedback. We will try to rectify it in the upcoming Nordic SDK update.

As a workaround, please consider marking the files you don’t need as “Excluded from build”. Unlike the list of files, this flag won’t get overridden when you change settings/frameworks in VisualGDB Project Properties.

[support]

 

Hi,

It looks like it takes VisualGDB over 30 seconds to parse the source file. It could be expected first time you parse a file with many includes (Boost would be a perfect example of that), but then VisualGDB should cache the header file contents and the subsequent operations should be much faster.

Also the refactoring should normally show the “Searching for references” window while it analyzes the source. It is by design that this window blocks the reset of the Visual Studio GUI as editing the code while it is being analyzed would lead to unpredictable results.

The last log snippet looks like VisualGDB fails to properly display a popup hint for some part of the code. It should not cause any slowdown or any other issues and can be safely ignored. If it looks like VisualGDB consistently doesn’t show a popup for some code where it should work, please let us know the repro steps and we will investigate it.

[support]

Hi,

If you are using an MSBuild-based project, please use VS Project Properties->C/C++ to set the language standard directly.

If you are using Make, CMake or QMake, please use VisualGDB Project Properties -> Build Settings -> CXXFLAGS.

[support]

Hi,

Please try installing VisualGDB 5.4 Preview 4 and the latest Segger package.

Then use the “reset device” checkboxes on the Debug Settings page or expand the “Advanced” view to directly edit the J-Link gdb server command line and/or startup commands.

If it doesn’t work, please attach a screenshot of your settings.

[support]

Hi,

Unfortunately this looks like an internal error in the gdb debugger. The only advice we could give here is to understand what is triggering it and try avoiding it, sorry.

[support]

Hi,

Good to know it works. If you encounter any further problems, don’t hesitate to contact us again.

[support]

Hi,

If you are using the Advanced CMake Project Subsystem, CMake directly reports a detailed project structure to VisualGDB, so as long as CMake can handle it, VisualGDB will work with it as well.

[support]

Hi,

We didn’t publish a detailed tutorial for the FX3 device as it’s not as mainstream as others (e.g. STM32), but we can easily share the details of the setup we used with Analyzer2Go.

We created a custom MSBuild-based project with manually imported sources and the linker script from the SDK. The debug process was relatively flaky through: Cypress provides a custom port of OpenOCD for the board, that unfortunately does not work very reliably. The setup that sort of worked for us was to program the FLASH memory using the Cypress tool, then launch their OpenOCD build (in the “custom gdb stub” mode) and connect gdb to it without reprogramming the FLASH memory.

If you are planning to use CMake, you can simply import your existing CMake project using the Embedded Project Wizard and then configure debug settings as described above.

Hope this helps. Let us know if you have any questions.

[support]

Hi,

We have released the updated VisualGDB 5.4 Preview 4 and the ESP32 toolchain (R10). Please try installing both updates and let us know if the problem is solved.

[support]

Hi,

Thanks for checking this. We should be able to help you resolve this if you could attach the output from the VisualGDB Diagnostics Console showing all command lines it launches and the corresponding output from valgrind.

[support]

Hi,

Thanks for mentioning that the project was upgraded from a Make-based one. This happens because GNU Make configurations require explicitly including the VisualGDB platform file, while the MSBuild configurations handle it automatically.

Although the message can be safely ignored, if you find it annoying, you can fix it by removing the following lines from your .vcxproj file:

 <ImportGroup Label="VisualGDBFindComponents">
 <Import Project="$(LOCALAPPDATA)\VisualGDB\FindComponents.props" />
 </ImportGroup>

Please note that it will break non-MSBuild configurations for the project, so we recommend removing them as well.

[support]

Hi,

If you are using the VisualGDB MSBuild backend, you can see why the linker is invoked by enabling verbose output:

Tools->Options->Projects and Solutions->Build and Run->MSBuild build output verbosity -> Detailed.

Then build the project and check for the “Re-linking <…> due to <…> message”. If you are not sure, simply attach the detailed build log here and we can help you understand it.

[support]

Hi,

You might be able to use the “adb connect” command (e.g. see our VirtualBox tutorial), however it might not work on your device, or might work unreliably.

[support]

Hi,

Yes, this is by design. The trial lets you evaluate all VisualGDB features and is hence equivalent to the Ultimate edition.

[support]

Hi,

If it is an external project managed by an external Makefile, the linker is likely re-invoked because the Makefile doesn’t handle dependencies properly.

You could try re-creating the project as an MSBuild-based project to let VisualGDB handle dependencies, although it might be non-trivial if the project has complex build settings.

[Author]

Posts