[support]

Hi,

@GeneM, it is hard to say why you would end up with 2 copies of the same BSP. VisualGDB has a mechanism for relocating the BSPs, leaving links to the new location behind, so it could be that you somehow triggered that one. Either way, the best way to get a clean BSP would be to close VS, delete %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32, and install the BSP again.

As for the old VisualGDB versions, you can download them here: https://visualgdb.com/download/oldversions

@bjornharink, thanks for the screenshot. It looks like you are using the Advanced CMake subsystem (that is the recommended way) that uses the toolchain path to cache toolchain-specific directories. If you installed the new toolchain in the same directory, it would indeed try to use old cached paths. The workaround is very straight-forward: just delete the <project directory>\.visualgdb subdirectory and reopen the solution. We have also fixed it on our side, so VisualGDB will now check both the toolchain version and the toolchain directory when deciding whether to reuse the cache.

[support]

Hi,

Thanks for sharing your feedback.

Most ESP-IDF releases indeed require a specific toolchain version and show an error message otherwise. This is exactly the reason why have separate prepackaged toolchains, each bundled together with a compatible version of ESP-IDF. The “debug methods” package (which is actually just OpenOCD) is usually backwards-compatible with older ESP-IDFs, hence it is shipped and installed separately (under %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.esp32.core).

We also have a documentation page explaining how different components of the ESP32 tooling work together, and how to troubleshoot (and avoid) most common problems. If you keep running into issues with every ESP32 update, please take your time to look through it – we made it based on the most common issues our users ran into, and it will save you a lot of troubleshooting time.

As for the project rebuild, normally just doing a “Build->Rebuild Solution” should automatically clean up the references to the old toolchain. This will work even if the project fails to load and shows an error message in Solution Explorer (unless the project was modified to reference specific things from the old toolchain). If you had to remove the build directory multiple times, something else (e.g. antivirus) might be interfering with the build.

[support]

Hi,

Thanks for renewing your license.

VisualGDB sets the IDF_PATH value based on the toolchain and ESP-IDF version selected in VisualGDB Project Properties -> ESP-IDF Project.

If your existing project stopped working after switching to a new toolchain, we would advise creating a new project for the new toolchain/ESP-IDF, making sure it works, and then using a diffing tool to compare the settings files (.vgdbcmake, sdkconfig, etc.) between the 2 projects.

You can also find detailed overview of the ESP-IDF project structure and troubleshooting tips here: https://visualgdb.com/documentation/espidf/

[support]

Update: the BSP has passed all our internal tests and has been released. You can download it via VisualGDB Package Manager as usual.

[support]

Thanks, we have rechecked stddef.h on Advanced CMake, but it looked just fine. Could you please attach a screenshot of the entire Visual Studio window, showing the error and the Solution Explorer window as well?

Regarding the “not implemented” warnings, it appears to be a feature of the new toolchain to warn you about these functions, however it does not indicate any actual error. We have updated our documentation here, explaining what causes it, and known workarounds.

[support]

Hi,

Could you please let us know the build subsystem you are using? Is it GNU Make, CMake or MSBuild?

[support]

Hi,

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey​

[support]

Hi,

Good to know it works. The exact path of platform.txt depends on how the package was installed (different Arduino IDE variants use different directories), but as long as you found the file, it should work just fine.

The Program and Start without Debugging is not a setting in VisualGDB Project Properties, it’s a command under the Debug menu in Visual Studio.

[support]

Hi,

Thanks for reporting this. It looks like the RP2040 platform definition uses a slightly unexpected syntax for the upload command template: program {{build.path}/{build.project_name}.elf} expecting it to expand to program {full-path.elf}.

Other platform definitions we checked used the “{{” to escape the “{” character, i.e. program {{{build.path}/{build.project_name}.elf}}.

Normally, you should not need this command at all – simply configure OpenOCD via VisualGDB Project Properties -> Debug Settings, and use Debug -> Program and Start without Debugging to program the FLASH memory using the VisualGDB-level commands.

If you would like to use the Arduino-level commands, you can also patch the C:\Users\<user>\Documents\ArduinoData\packages\rp2040\hardware\rp2040\<version>\platform.txt file by inserting the extra “{” and “}” to make it consistent with other platforms:

tools.picoprobe_cmsis_dap.upload.pattern="{cmd}/bin/openocd" -f "interface/cmsis-dap.cfg" -f "target/rp2040.cfg" -s "{cmd}/share/openocd/scripts" -c "adapter speed 5000" -c "program {{{build.path}/{build.project_name}.elf}} verify reset exit"

Please make sure you reload the project after patching the file.

We will consider updating VisualGDB to handle it automatically, however as we want to minimize the chance of breaking other platforms, and as there are 2 easy workarounds, we will wait for feedback from other users before updating it on VisualGDB side.

[support]

Hi,

Sure, you can use the per-user variables as shown below

• Set the default value to the normal location.
• Try redefining it for your own user account and check the <Project>-<Configuration>.vgdbsettings.<User name>.user file where VisualGDB would store the per-user value.
• Update the Jenkins build script to generate a similar .user file (with the user account name used by Jenkins, try “echo %USERNAME%” if not sure) with the correct per-build value.

If you are not planning to use any other per-user settings, you can also use the following syntax when generating the .user file (instead of XML):

#comment
VariableName1 := VariableValue1
VariableName2 := VariableValue2

[support]

Hi,

The new BSP has not been publicly released yet – we are still running final tests on it and will be releasing it next week.

There was a glitch on our side that initially marked the BSP as public, so if you checked for updates within a ~1-hour interval before we fixed it, VisualGDB would indeed show the incorrect link.

You can simply ignore it for now (or delete %LOCALAPPDATA%\VisualGDB\PackageCatalog.xml to reset the cache). Once we finish all the tests and release it, VisualGDB will use the correct link.

[support]

Hi,

This looks like your toolchain might be corrupt. Please try using a clean toolchain and a matching SD card image asd shown on https://gnutoolchains.com/raspberry/. If it doesn’t help, please try dumping the configuration and build commands to batch files and running them manually as  shown here: https://visualgdb.com/documentation/projects/cmake/#troubleshooting

If building the project manually doesn’t work either, please double-check your antivirus. It might be preventing parts of the toolchain from starting properly.

[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. See this page for more information and detailed examples.
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.

Another common cause of errors is updating to a new toolchain/BSP/SDK. Many of these components are maintained by device vendors or communities, and require minor adjustments to the project when switching to newer versions. If you have recently updated any of such components, please consider reverting back to the old version as described here. There is no need to downgrade VisualGDB itself, as it is updated separately from such components.

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,

Most likely, you ended up updating some of the components (e.g. BSP or some libraries to versions  that  are not 100% backward-compatible, and  then tried to troubleshoot it by changing some setting that ended up breaking the project.

Unfortunately, the issues you are describing do not look like a known issue, so our best advice would be to revert everything to the latest version that worked.

If you can point a specific setting or update that breaks the project, we can gladly investigate it further.

[support]

Hi,

Sure, VisualGDB expands the Windows environment variables the same way it does for internal variables like $(ProjectDir). So you could update your Jenkins script to set a variable (e.g. BuildNumber) and then use $(BuildNumber) in the remote directory path in VisualGDB Project Properties.

[Author]

Posts