[support]

Hi,

Most likely, you are trying to import a project generated with an older version of  the STM32CubeIDE that specifies some settings differently. The easiest way to get it working would be to compare its .cproject file against one of the .cproject files that get imported successfully (e.g. from the STM32 SDKs), specifically looking for the com.st.stm32cube.ide.mcu.gnu.managedbuild.tool.c.linker.option.script option.

If it doesn’t help, please feel free to attach the .cproject file (please place it into a .zip archive if you would like to attach it here) and we will recheck why the STM32IDE importing plugin doesn’t work with it.

[support]

Thanks for renewing your support. Instrumenting the code for profiling could result in crashes if the original code was corrupting the memory, had possible race conditions or other implicit dependencies.

In order to troubleshoot it, please try the following:

1. Instead of using the Analyze command, try enabling real-time watch in VisualGDB Project Properties -> Dynamic Analysis, but don’t create any watches yet. Does this result in a crash?
2. If yes, please try changing the instrumentation settings on the Dynamic Analysis page to only instrument one or two functions (e.g. the one controlling the LED). Does the code still crash?
3. If instrumenting only one function stops the crashing, the problem is caused by instrumenting some of the low-level system functions. Please try excluding all low-level functions from being instrumented to see if it solves the problem.
4. If instrumenting only one function still causes crashing, please try reproducing the problem on a clean project created from scratch for the same device. Once you get it reproduced, please share the repro project with us and we will investigate it further.

[support]

Hi,

We normally advise using our CMake fork when building projects on the Windows side, as we routinely test various VisualGDB features with it. That said, you can configure VisualGDB to use a specific CMake executable via Tools->Options->VisualGDB->General->Tools->Full path to cmake.exe.

We have also updated our CMake fork based on the latest v3.20.3 release. You can update it via Tools->VisualGDB->Manage VisualGDB Packages.

[support]

Please let us know the exact names and full paths of the .hex files you located, so that we could recheck what is going on.

[support]

Hi,

This error would appear when VisualGDB could not find any zephyr.hex or merged.hex files in the build directory. Normally, they should be produced by the Zephyr build and are used by VisualGDB to include the softdevice into the ELF file that will be loaded into gdb.

Please try checking the C:\Embedded\Embedded\build\nrf52dk_nrf52832\Debug\zephyr directory for *.hex, *.bin and *.elf files.

If the hex file is not created, it could have been disabled via Zephyr settings. Please try checking if the problem persists with a freshly created project. If not, please try comparing the settings between the 2 projects and adjust the initial project accordingly.

[support]

No problem and good to know it works. It’s hard to say why it would get placed into the root folder – it could be a side effect of a specific combination of settings. If working around the problem by deleting the file works for you, no further action is necessary. If it becomes more annoying, or you suspect that there’s a bug in VisualGDB affecting the project layout, feel free to attach the repro steps and we will investigate it further.

[support]

Hi,

Unfortunately, it’s hard to suggest anything specific based on the description you provided. Please try reproducing the problem on a freshly created project. If it persists, please share the full steps to reproduce the issue from scratch, including all the relevant screenshots per our problem reporting guidelines.

[support]

Hi,

The newer builds usually include all the fixes from the older builds (unless they have been removed due to problems with other functionality), hence it should work.

The problems are likely caused by something else. Please feel free to share the details on the errors you get (and also renew your support here as it has recently expired) and we will help you get it working.

[support]

Hi,

It looks like you are using a relatively old preview build. Please try updating to the latest one: VisualGDB-5.6.1.4124.msi

[support]

Hi everyone,

Thanks, we confirm that VS 16.10 is missing one of the classes used by language services (such as Clang IntelliSense) to query information from Visual Studio using the backward-compatible COM interfaces. We are working on this and will release a hotfix in the next couple of hours.

Update: we have added a workaround to the issue to the following build: VisualGDB-5.6.1.4119.msi. We will also release hotfixes for VisualGDB 5.5 and VisualKernel 3.1 soon.

Update #2: we have also released VisualGDB 5.5R5 and VisualKernel 3.1R9 that include a fix to this issue. You can get them via the regular download pages if you do not want to install the beta.

• This reply was modified 4 years, 5 months ago by support.
• This reply was modified 4 years, 5 months ago by support.

[support]

Hi,

The STM32CubeMX tool indeed often generates somewhat broken code. Unfortunately, the exact behavior varies from version to version, and some configurations of settings indeed require manual adjustments.

Adding a brand new setting to cancel out automatically imported include directories could create unnecessary complexity (e.g. forgetting about that setting would make it look that the regular Include Directories setting got totally broken). Instead, we would advise simply patching the STM32CubeMX importing plugin. It is fully open-source, so you can simply modify it to exclude certain include directories that match a certain pattern (e.g. before the ApplyFreeRTOSFixes() method is called), and replace the version shipped with VisualGDB by the customized version.

If the behavior isn’t fixed on the ST side in a couple of months, please feel free to post an update here and we will recheck it and include a permanent fix for it on our side.

[support]

Sorry, we have tried just that when you first reported it, and it built successfully. As you have not provided the complete screenshots of all related wizard and settings pages per our previous reply, it is hard to suggest anything else.

Most likely, you have edited some code on your side at some point. Either way, we will keep an eye on it and will investigate it further in case other users report similar issues.

[support]

If you can confirm that a project created from the VisualGDB template without any modifications doesn’t build out-of-the-box, we can gladly investigate and fix it.

If this is the case, please provide complete and full steps to reproduce the problem from scratch, including a screenshot of every wizard page and every settings page involved in the repro. See our problem reporting instructions for more details.

[support]

Hi,

Just wanted to point out that this is outside the scope of the VisualGDB support. You are welcome to ask for advice from other users, however we won’t be able offer any help with this issue.

Please feel free to contact Espressif, or post on the ESP32 forums for all questions about the internals of ESP-IDF or the ESP32 Arduino core.

We will move further out-of-scope inquiries on the topic into this thread to avoid duplication.

[support]

Hi,

This is by design. The project you are trying to build contains an error and VisualGDB displays it. Please make sure you can build the project outside VisualGDB first, and you will be able to build it with VisualGDB as well.

[Author]

Posts