[support]

Hi,

You can try contacting Espressif for help, or patching the ESP-IDF build scripts yourself. VisualGDB works on top of the existing scripts and cannot do it for you.

The “program from file” option programs the specified file into the bounds of the partition reported by ESP-IDF. This is done once and does not change the ESP-IDF project properties, or override the regular ESP-IDF programming logic.

[support]

Hi,

No problem, this looks like a known issue that is already fixed in our development branch. Please try this build: VisualGDB-5.6.106.4630.msi

We are maintaining our NRFConnect support. We periodically check compatibility with the latest SDK versions, update VisualGDB accordingly and are happy to offer numerous productivity features that make VisualGDB development experience better compared to VSCode.

[support]

Hi,

The exact FLASH command line is not directly under VisualGDB’s control, however we can explain what parts are involved in computing it so that you can pinpoint the correct setting:

1. ESP-IDF enumerates all KConfig files referenced by the project and stores them in the project_description.json file.
2. VisualGDB scans the KConfig files referenced there and shows the ESP-IDF-specific settings based on them.
3. When you change those settings in the GUI, VisualGDB updates the sdkconfig file.
4. When you build the project using ESP-IDF scripts, they pick up the settings from sdkconfig, and compute various command lines based on them.
5. Some command lines are saved to intermediate files such as flash_args

Modifying flash_args manually will indeed not work, since the build scripts will overwrite it. Instead you would need to find the ESP-IDF setting that controls its content and change it (either by editing sdkconfig directly, or via VisualGDB Project Properties that will let VisualGDB edit it for you). Searching ESP-IDF build scripts for flash_args or parts of the command line shown there could be a good starting point.

[support]

This is by design. Normally, VisualGDB sorts groups source files reported by CMake based on their physical directory, i.e. separating the PicoSDK Files from the rest of the files.

Once you create a virtual folder, VisualGDB assumes you want to rearrange them manually, and stops grouping them by paths, allowing you to drag them into the virtual folders of your choice. The virtual folders are completely separate from the physical folders and are stored in the .vgdbcmake file. This feature is meant for projects where many files are stored in the same directory, and the existing path-based grouping is not convenient.

If you would like to group your source files better, while relying on VisualGDB to separate the SDK sources, we would advice moving your sources to physical subdirectories, and updating the CMakeLists.txt file accordingly. VisualGDB will automatically show these subdirectories in Solution Explorer, as long as you have no virtual folders and have not disabled path-based grouping.

[support]

The exact steps to enable verbose logging depend on your project type. You can find them for most of the project types in our documentation.

If it doesn’t help, please let us know the exact project type you are using (i.e. what was selected on every step of the wizard) and we will point you to the relevant documentation.

[support]

Hi,

This is to be expected, as our tutorial is for the STM32F407VG device. Copying device-specific code into a project targeting a different device will indeed most likely result in various errors.

That said, different STM32 families use fairly similar APIs, so porting the code between them should be fairly easy, as long as you understand the differences between them. Looking through ST documentation/samples could be a good starting point.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.

[support]

Hi,

Normally, the hex files should not have any adding at all – the areas between the sections are simply excluded from the file. Either way, VisualGDB generates these files via the objcopy tool from the toolchain. You can try copying the tool command line from the build log, running it manually and experimenting with various options.

Alternatively, you can try using .bin files – VisualGDB explicitly passes the –gap-fill argument to objcopy when generating them, controlling the filler value between the sections.

[support]

Hi,

This is by design. It is not viable for us to ship a separate LEDBlink sample for every possible board on the market. It is up to you to review the schematics of your board and select the values that would work.

[support]

Thanks, we have confirmed that configuring VisualGDB to synchronize a directory with a specific IP address during project loading (as opposed to building) and then changing that IP address without updating the VisualGDB project indeed prevents the project from loading correctly.

As the issue is only triggered under a very specific configuration, we will fix it in one of the upcoming VisualGDB updates and will not produce an immediate hotfix.

As a workaround, please consider using the hosts file to define persistent names for your VMs so that you won’t need to change the project settings every time.

[support]

Sorry about the confusion.

The indentation settings shown in the diagnostic log are taken from Tools->Options->Text Editor->C/C++ (VisualGDB)->Tabs. The clang-format file should normally override them, but if it’s not happening, you can always change them manually via the VS Options window.

[support]

Hi,

VisualGDB uses the same API for resolving host names as other Windows commands. So if the “ping” command doesn’t see your host names, VisualGDB won’t see them either.

Specifying the IP address manually and changing it via project settings should work just fine – clicking “Cancel” in the connection progress dialog should stop the project from loading, but should not prevent you from changing the settings.

If it still doesn’t work, please  provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side. Please do not block parts of the screenshots showing the values of different settings. They are critical to finding the cause of many issues. If you do not wish to share sensitive information, please reproduce the problem on a simplified setup involving test projects and computers.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

[support]

Hi,

This looks like an issue with your network settings. Please try checking if running “ping <VM name>” picks up the new IP address of the VM. If not, VisualGDB would not pick it up either.

[support]

Thanks for the detailed repro steps. It looks like your .clang-format file is corrupt or contains statements that are not supported by Clang 6.0 used by VisualGDB:

Error HRESULT E_FAIL has been returned from a call to a COM component. while trying load C:\Users\otodu\Downloads\VisualGdbTest\.clang-format

Please try narrowing this down to a specific statement/line that prevents the file from being loaded. E.g. you can remove half of the statements and check if the file still loads. If yes, restore half of the previously removed ones, and try again.

If you can pinpoint a specific statement that is not loaded properly, please let us know and we will provide more details.

[support]

Hi,

VisualGDB itself doesn’t have any special GUI for discarding individual sections, however you might be able to get it working as outlined below:

1. Completely disable FLASH loading on the VisualGDB side.
2. Use the objcopy tool from your toolchain to discard individual sections from the ELF file (see binutils documentation) and save the result separately.
3. Manually configure gdb to use one image for debugging, and another image for actually loading into the target . Then manually load the second image into the target. See GDB documentation for the specific commands to use.

You can configure VisualGDB to run objcopy after the build via VisualGDB Project Properties -> Custom Build Steps, and to issue additional commands to GDB via VisualGDB Project Properties -> Additional GDB commands.

[Author]

Posts