[support]

Hi,

Thanks, this explains it. VisualKernel automatically shows suggestions for COM ports up to COM4 (ttyS0..ttyS3), however as you needed to use ttyS4, you likely entered it manually, with the “/dev/” prefix, confusing the KGDBoC module.

We have updated VisualKernel to explicitly mention the parameters echoed to the parameters file in the error message, to make it easier to diagnose this type of issues. We have also added COM ports up to COM8 (ttyS7) to the selection list.

Feel free to try this build: VisualKernel-4.0.101.2357.msi

[support]

Hi,

It worked just fine in our tests, so most likely you are doing something different.

You can try using the Debug->Attach to Running Embedded Firmware command to attach to it once the problem manifests itself, so that you could see what the device is doing.

[support]

Hi,

Thanks for your clarification. VisualKernel handles KGDBoC as follows:

1. Runs “cat /sys/module/kgdboc/parameters/kgdboc” on the target and compares the output with the contents of the <KgdbocArguments> element in the .vkrnlproj file.
2. If they are different, runs “sh -c “echo <args>” > /sys/module/kgdboc/parameters/kgdboc“. If this command fails, it displays the “cannot configure KGDB” error.

Based on what you are describing, it looks like the KGDBoC parameters configured via VisualKernel GUI are rejected by the kernel and it ends up with KGDBoC disabled. You can verify it very easily by comparing the contents of the <KgdbocArguments> element to”ttyS4,115200“. If it’s different, you can just patch it manually and reopen the solution – VisualKernel will then try to use the KGDBoC configuration you entered manually.

 

 

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

[Author]

Posts