Forum Replies Created
-
Posts
-
Hi,
Looks like the Jenkins machine is missing VisualGDB toolchain definitions. This is very similar to the issue discussed in this thread, so the workarounds described there should work.
If not, please let us know more details and we will help.
Please note that we usually respond to most inquiries within 24-48 hours.
Please note that VisualGDB uses the original GCC toolchain (i.e. the GNU linker) to link the projects. You can find the linker command line used by VisualGDB per our troubleshooting instructions. VisualGDB itself does not introduce any additional logic on top of what is done by the GNU linker.
Generally, we are not able to provide insights into the inner workings of the open-source tools used by VisualGDB, as they often involve very complex logic. Please consider community-driven resources like StackOverflow to get help with open-source tools.
If you are looking for a fully supported compiler, please consider using VisualGDB with IAR or Keil. This way you can still enjoy the VisualGDB features, and get compiler-specific support from IAR/Keil teams.
No problem, we will explain what is going on.
In order to avoid hardcoding toolchain parameters (e.g. the exact path) in the project files, VisualGDB maintains a per-user registry of installed toolchains under %LOCALAPPDATA%\VisualGDB\ToolchainProfiles. This registry is updated each time VisualGDB is loaded in Visual Studio (e.g. when opening a project) and is explicitly rebuilt when you run the Tools->VisualGDB->Manage VisualGDB Packages command. You can find a detailed documentation on the toolchain registry here: https://visualgdb.com/documentation/toolchains/#troubleshooting.
The “missing toolchain profile” error happens when you try to build a project that references a toolchain that is not present in the toolchain registry. Most likely, your CI setup is using a different user account (and hence a different %LOCALAPPDATA%, so VisualGDB never gets a chance to update the toolchain registry in that environment).
You can work around it via one of the following ways:
- Manually copy the relevant parts of the toolchain registry to the %LOCALAPPDATA% of the CI user account.
- Since VisualGDB’s MSBuild subsystem builds remote projects by generating a temporary Makefile (or a ninja file), you can locate it on the development machine, check it into source control, and configure your CI environment to build it instead. This way you won’t need to install neither VisualGDB, nor Visual Studio on the CI machine, however you would lose the ability to run VisualGDB-level custom actions.
Let us know if you have any further questions and we will be happy to help.
Please try installing VisualGDB 5.5 Preview 7 from our download page instead. It should include the latest updates.
It the problem persists, please let us know and we will investigate it further.
No problem, please try this build: VisualGDB-5.5.7.3703.msi
Thanks for reporting this. We have fixed the issue in the following build: VisualGDB-5.5.7.3703.msi
No problem. This looks like a bug triggered by a combination of the “indent braces” style, disabled auto-pairing of brackets, and disabled auto-reformatting of statements. Since this combination of settings is very rare, indeed it was not covered by our tests.
We have fixed it in the following build: VisualGDB-5.5.7.3703.msi
Either way, you can disable VisualGDB’s code formatting logic if you switch from Clang IntelliSense to the regular VS IntelliSense (only works with projects based on VC++). You can find a detailed description of supported scenarios here: https://visualgdb.com/documentation/intellisense/.
You can also find a searchable list of all VisualGDB settings automatically updated from the latest VisualGDB build here: https://visualgdb.com/settings/
Hi,
No problem, please try this build: VisualGDB-5.5.7.3701.msi
Just wanted to share an update that we have added support for the WICED SDK to the following build: VisualGDB-5.5.7.3700.msi.
You can now create a basic project using the new WICED project wizard.
If you are using PSoC 6, make sure you use the latest OpenOCD package and configure the debug package per attachment.
We will publish a detailed tutorial in the next couple of weeks as well.
No problem, we have fixed the issue in the following build: VisualGDB-5.5.7.3700.msi
Hi,
No problem, we have reproduced and fixed the issue in this build: VisualGDB-5.5.7.3700.msi
Good to know it works. In case anyone else encounters the problem, you can configure the root source folder uploaded by VisualGDB as a part of the build via VisualGDB Project Properties -> Project Settings -> File Synchronization or define additional directories to transfer via VisualGDB Project Properties -> Synchronized Directories.
Hi,
Thanks for your suggestion.
The trouble with the PSoC devices is that they rely on an extremely complicated software framework, and at the same time have relatively few users, compared to mainstream device families like STM32.
We have done some tests with the PSoC6 using the WICED SDK and will be supporting it similar to the recently added nRFConnect SDK support. However, as the PSoC devices are less popular than mainstream families like STM32, the support for them will be somewhat basic, compared to the STM32 devices.
That said, you can always create a project manually by following our legacy device tutorial.
Yes, the Embedded edition supports these frameworks.
However, please be advised that both ESP-IDF and ESP-ADF are very complex frameworks maintained by Espressif and they often don’t work as expected. While VisualGDB includes a convenient GUI layer on top of these frameworks, it inherits all their limitations and bugs. I.e. the VisualGDB license does not cover troubleshooting of issues inside these frameworks, or help with specific projects, as it would cost much more than we charge per license. We strongly advise trying out multiple sample projects with these frameworks during the evaluation period, and making sure you are happy with their reliability and quality.
Hi,
The easiest way to do this would be to use Embedded Quick Debug.
