[support]

Thanks for the screenshot.

It looks like you are using ESP-ADF, not the regular ESP-IDF, and there was indeed a bug in VisualGDB preventing it from showing the device list for ADF projects.

Please try this build: VisualGDB-5.6.108.4753.msi

[support]

Hi,

You can change the device type via VisualGDB Project Properties -> ESP-IDF Project -> Configuration Settings -> Device.

[support]

Hi,

This happens because CMake projects contain multiple targets, and setting the target_compile_definitions() for one target does not automatically affect others.

You can find the list of targets (executables + static libraries) in Solution Explorer, or by analyzing the target-XXX.json files in the .visualgdb\VisualGDBCache subdirectory.

If you are trying to setup a complex project layout involving multiple targets, we would advise first sketching how many targets it would involve, how they would reference each other, and then setting up the target_compile_definitions() accordingly. If you are new to CMake, we would advise reading about the public/private/interface definitions – it will help you setup everything efficiently.

You can also use our CMake Debugger to step through the CMakeLists files and see how and where various settings are applied.

[support]

Thanks, we have received and reviewed the dump file. The crash happens because Clang considers one of the headers it’s precompiling to contain a typo preventing the normal parsing, and it apparently triggers a “not implemented” condition when trying to produce the precompiled header data.

You can work around it by adding a non-preprocessor statement (e.g. ‘static int unused=0;’) at the beginning of the file to suppress the precompiled header generation. Then you can try moving the statement between the #include<> directives until you find the one that is triggering the issue. Having that include directive after the non-preprocessor statement will prevent Clang from trying to precompile that header file, working around the crash.

[support]

Hi,

Normally VisualGDB should automatically create a dump file containing sufficient information for us to pinpoint the issue. If this doesn’t happen, please try attaching another VS instance to the CppEngineHost64.exe process (make sure you explicitly select the Native mode), wait for the crash to happen and then create a dump file via the Debug->Save Dump command.

You can attach the dump file here, or simply submit it to us via the support interface and we will try to find the root cause of the issue and release a hotfix.

[support]

The target-independent parts of VisualGDB (.Net IL libraries) will indeed work. However, the native parts (x86 and x64-specific) will not. Furthermore, all external tools (e.g. OpenOCD, toolchains) will have to rely on the x86 emulation, making them considerably slower. Driver compatibility could be another big issue.

So, it could be fairly easy to get it to a proof-of-concept level, but getting a reliable development environment that can be used for non-trivial projects could be orders of magnitude more complex, and may still not work out due to lack of support from external tools.

We will watch the user interest in ARM64 and the adoption of the Windows ARM64 platform by the GNU tool ecosystem, and will add support for it when there is enough momentum. If you are serious about using an ARM64 Windows host for development with GNU tools, please consider contributing to the ARM64 MinGW port. It will speed up the ARM64 adoption by the community by making it possible to do native builds of tools like OpenOCD and GCC/GDB. Once these tools are natively supported and start being used by the community, the ARM64 port of VisualGDB will make more sense.

[support]

Thanks for letting us know and good to know it works.

[support]

Hi,

We are aware of that. ARM64 laptops are still very new, relatively rare, and are seldom used as development workstations. Hence, VisualGDB does not support running on the ARM64 Windows builds.

We will continue monitoring the situation and will consider supporting ARM64 development machines if they become more popular among developers.

[support]

Thanks for confirming this and good to know it works. BTW, if you change your build environment in a minor way (e.g. add new libraries to the setup), you don’t need to rebuild the entire toolchain, as long as the gcc version and ABI (e.g. floating point mode) stays the same. Running a “bitbake build-sysroots” and replacing the sysroot directory in the current toolchain should do the trick.

[support]

Thanks, it looks like gdb never reports a successful connection to the J-Link GDB server. Please try running both of them manually:

C:\Program Files\SEGGER\JLink_v780a\JLinkGDBServerCL.exe -select USB -device NUC029LEE -speed 33000 -if SWD -port 50692

and gdb:

C:\Program Files (x86)\Sysprogs\VisualGDB\Keil\arm-none-eabi-gdb.exe “D:\@coding\@bce\ap8557cdma\_AP8557x1.0828t191Bx0821V2(REV)_220118R0_Lib\.project\vgdb\AP8557V2REV\VisualGDB\Debug\AP8557V2REV.elf”
target remote :50692

Does it result in a successful debugging session? If not, please try disabling your firewall/antivirus and using a different port number.

[support]

Hi,

This looks like a corrupt toolchain. Please try deleting it and reinstalling it via the VisualGDB Package Manager.

If it doesn’t help, please try disabling your antivirus. It might be interfering with invocation of some components.

[support]

Thanks for renewing your license.

For RP2040 projects there are 2 different FLASH sizes:

• The FLASH size displayed in the Memory Explorer is taken from %VISUALGDB_DIR%\rules\PicoSDK.xml (search for MemoryMap). It is only used to calculate the utilization percentage and can be changed by editing the rule file.
• The actual memory layout is managed by the PicoSDK build system. VisualGDB does not control it directly and lets the PicoSDK manage it.

If you would like to change the actual memory size used for linking, a good starting point would be the default linker script (try adding “-v” to Ninja arguments, re-link the project and search the build log for “.ld” or “-T”). Once you locate the default linker script, you can patch it to have the memory size you prefer, or fork it and patch the PicoSDK CMake files to use the modified version of the script.

[support]

Please note that OpenOCD is an external open-source tool maintained by the OpenOCD community. When you install it on your Raspberry Pi via VisualGDB GUI, it simply clones the project repository and attempts to build and install it. As it is often the case with open-source projects, it may require some minor fine-tuning and adjustments and it is not something that VisualGDB can do fully automatically.

If you are looking for a fully supported out-of-the-box solution, please consider using Segger J-Link. It comes with its own proprietary replacement to OpenOCD that is well-tested and fully supported. VisualGDB supports both OpenOCD and J-Link equally well, so our users can choose the underlying debugging software that works the best for them.

[support]

Hi,

It looks like gdb manages to connect to J-Link and then disconnects. Please try collecting and analyzing the GDB log as shown here: https://visualgdb.com/support/logsubmit

[support]

Hi,

The script names could slightly vary for different OpenOCD versions or devices. The VisualGDB device/interface script selectors always show the script names from the local machine, so if the remote machine uses different scripts, you would need to find them out and enter the names manually under “advanced settings”.

If you would like to use VisualGDB with OpenOCD that runs on a Linux machine, we would advise first getting it to work manually (i.e. ensure that it works when you launch it via an SSH terminal). If you need help with this, please consider asking on the Raspberry Pi community or in OpenOCD mailing lists, as it is not specific to VisualGDB.

Once you get OpenOCD working, you can manually enter the script names in VisualGDB Project Properties and VisualGDB will handle launching and connecting to OpenOCD automatically.

[Author]

Posts