[support]

Hi,

It looks like due to the low speed of the COM port, gdb times out before it manages to connect to the target. We have updated our KGDBoC tutorial, showing how to increase the timeout.

Also, feel free to try this build [VisualKernel-4.0.101.2354.msi], it will automatically apply increased timeout for KGDBoC connections.

If it doesn’t help, please try adding the “set debug remote 1” command as shown in the tutorial and share the GDB log so that we could recheck what is going on.

[support]

Hi,

The problems with changing the ESP-IDF version and target happen because different ESP-IDF versions/targets are not 100% compatible. Some APIs or build settings are different and VisualGDB cannot automatically translate them between the versions because there are no machine-readable translation rules.

Hence, the recommended way of migrating projects to new targets or ESP-IDF versions is to:

1. Create a new project from scratch, make sure it builds.
2. Switch your existing project to the new ESP-IDF version/target.
3. Manually troubleshoot the remaining issues by comparing the switched project to the project created from scratch.

[support]

No problem and thanks for providing the detailed repro steps so that we were able to reproduce the issue.

[support]

Hi,

The instrumentation-based profiling should work just fine and does not require any special drivers. If the project doesn’t build, you can disable the sampling profiler code via VisualGDB Project Properties -> Embedded Frameworks.

Sampling profiler indeed requires a slight tweak to the STM32 drivers we have, and we can gladly add it if requested by any of our paid users. If you have purchased a license, please let us know the email address associated with it, and we will gladly updated our driver.

[support]

Please contact Espressif directly for all questions about ESP-IDF and other tools provided by them.

[support]

Hi,

This is to be expected. The master branch of ESP-IDF is untested, often doesn’t work on Windows, and may require some tweaking to get working.

Once Espressif resolves these issues and gets confident about the quality, they usually publish it as a stable release, and we release a toolchain that includes it and works out-of-the-box. If you do not want to wait for that and would like to try the pre-release build, you will have to troubleshoot it yourself, sorry.

[support]

You can use the minimal “Blinking LED” example included with our STM32 BSP by keeping default options everywhere in the Embedded project wizard. It will work out-of-the-box, as long as you replace the GPIO port/pin numbers with the ones relevant to your board.

If you are trying to import code that comes from elsewhere (namely, the STM32CubeMX generator), please don’t blame VisualGDB if that code doesn’t build or work.

[support]

Hi,

VisualGDB could be a good place to start if you are willing to separate VisualGDB-specific issues from the target-specific issues, and investigate the latter type on your own. Makefiles are not specific to VisualGDB, you can find lots of documentation and examples online (even specific to STM32CubeMX), and you will need that knowledge (or more specifically, a good understanding how C++ compilation/linking works and how to troubleshoot common errors) if you are planning to do any non-trivial development.

VisualGDB will save you a lot of time via its code navigation, live debugging features, and convenient GUI for editing various settings, but it’s up to you to take your time, read some online tutorials and understand how these settings work, where different parts of the project come from, and how to troubleshoot the cases where some of these parts don’t work together.

In our experience, users new to embedded development tend to underestimate the complexity of the embedded workflow and often expect VisualGDB support to handle issues that are a part of the normal project development cycle. This never works. Each time we tried to help and investigated them on behalf of our users, they would come back with more, the complexity of the issues would increase exponentially, the deadlines would get tougher, and users would eventually abandon the project, blaming VisualGDB for it.

We do not want our users to go down that spiral. We are happy to support them getting the best productivity out of VisualGDB’s features (in addition to the extensive documentation we have here), however we do expect them to be able to build their code outside VisualGDB and know how to fix issues in it. It doesn’t mean that you will need to do it for every project – VisualGDB provides numerous troubleshooting features (e.g. header discovery), but they rely on the user to have a good idea of the underlying project structure and semantics of various involved tools. And building the project manually (that will involve a lot of googling and trial-and-error) is a good way for a beginner to get familiar with these tools.

If you are not willing to do this, VisualGDB (or any other IDE really) won’t really work for you. Embedded projects often include code from multiple different vendors (even in your most basic STM32CubeMX example) and there are often rough edges that no software tool can fix automatically. For what it’s worth, the project templates included in our STM32 BSP will build out-of-the-box, because we tested them before releasing the BSP, and manually fixed a few minor issues present in the original SDK. If you are importing the code from elsewhere, it’s up to you to make sure it can be built – VisualGDB won’t do it for you.

[support]

This is correct. We only provide toolchains for stable ESP-IDF releases. If you would like to use pre-release ones, it’s something to do on your own risk.

[support]

Hi,

You can try generating a Makefile with STM32CubeMX and building it manually. If the generated Makefile builds for the same project on the same device without errors, while the VisualGDB-based project doesn’t work, we can help you compare the 2 projects an find what causes the difference. Just make sure you are using the same build type (debug vs. release) in both cases.

[support]

Hi,

It looks like an issue with your toolchain and not with VisualGDB. Please make sure you can build the same project with the same toolchain manually.

[support]

Hi,

Good to know it works. Using git, or taking brief notes of the settings you change, could indeed save lots of time tracking down such issues.

[support]

Hi,

This means that the project you are trying to build does not fit into your device’s RAM. You can try building it for a different device and use Memory Explorer to analyze the memory usage so that you could reduce it.

[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.

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,

Method extraction is not yet supported, as it would rely on a refactor script API that is not yet available. VisualGDB supports a lot of other refactorings and provides convenient scripting mechanism for defining your own ones, but it does not support extracting methods yet. Creating methods from use and implementing interfaces is fully supported though.

[Author]

Posts