Forum Replies Created
-
Posts
-
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
You can find various tutorials on many different setups on the following page: https://visualgdb.com/tutorials/
That said, we publish our tutorials to show how to use various VisualGDB functionality in complex real-world scenarios, so that our users would know how to efficiently automate similar tasks with the demonstrated VisualGDB features. Many tutorials involve external components maintained by other vendors (e.g. the ESP32 Arduino core) and we are not able to take over the maintenance and troubleshooting of these components, or guarantee that every version of these external components will always work flawlessly and will be 100% compatible with other components. If you encounter errors in code that is not maintained by us, please consider containing the maintainer of the code (e.g. Espressif) for help.
This can be caused by the differences in how STM32CubeIDE and VisualGDB handle OpenOCD scripts.
STM32CubeIDE generates a per-device OpenOCD script that sets various variables and includes one of the regular scripts (e.g. stm32h7x.cfg). VisualGDB instead allows overriding these variables via command line (it automatically shows GUI for supported variables) and then includes one of the regular scripts directly via the “-f” argument. This works well for the devices we tested, however might miss some undocumented variables that could be set by STM32CubeIDE for your device.
The easiest way to get everything working would be to copy the OpenOCD script generated by STM32CubeIDE into your project directory and reference it from the OpenOCD settings. You can also try reviewing its contents and comparing it with the setup when you select one of the scripts via VisualGDB GUI. If there is any obvious difference, we might be able to add a GUI setting accommodating it.
Hi,
Thanks, indeed the ST fork of OpenOCD would not appear for STM32CubeMX-based projects. We have fixed it in this build: VisualGDB-5.6.1.4114.msi
You would also need to delete and re-download the ST fork of OpenOCD via Tools->Manage VisualGDB Packages.
