[support]

Please follow the tutorials.

[support]

Hi,

We have just rechecked the latest ESP-ADF framework. Just as our tutorial mentions, it doesn’t work with the latest GCC 8.x, but does work if you install GCC 5.2.0. This happens because ESP-ADF is based on an older ESP-IDF, that expects that specific old compiler version. Most likely, you ended up using GCC 5.2.0 with VS Code and GCC 8.x with VisualGDB.

Please double-check your GCC versions in the toolchain selection drop-down and make sure you are using GCC 5.2.0 with ESP-ADF as explained in the tutorial.

[support]

Hi,

As you have never provided the complete non-ambiguous steps to reproduce the problem from scratch, all we could do is re-run our standard coverage tests on a STM32CubeMX project during the v5.6 Beta 3 release cycle. They did uncover a glitch that could be causing this issue and we have fixed it in the Beta 3. Please try downloading and installing it from the download page.

[support]

Hi,

Sorry, this is by design. The “transfer files” command is intended for transferring them to/from Linux hosts and will not work between 2 local directories.

As a workaround, please consider launching xcopy.exe as a custom pre-build step to copy files within the Windows machine.

[support]

Hi,

Please double-triple check that you are importing the correct project. The import logic of the wizard never generates any new files, it simply references existing files linked by the project file. You can find out the full path of the file containing the main() function by right-clicking on the tab header  in Visual Studio and selecting “Copy full path”. You can then compare it with the path of the file in the original STM32CubeIDE project.

[support]

Hi,

As far as VisualGDB is concerned, it will handle the semihosting calls regardless of the interrupt context. So it semihosting is not working, the underlying library is not issuing the semihosting calls properly. You can track it down by disabling semihosting handling on the VisualGDB side and calling printf() outside an interrupt handler. The semihosting call trigger by it will cause the debugger to stop like it was a breakpoint, so you can analyze the call stack, and then review the C library sources to understand why this branch of code is never reached within an active interrupt.

[support]

Hi,

It looks like something is preventing OpenOCD from creating a temporary file:

Debug: 1490 5911 command.c:146 script_debug(): command – dump_image C:/Users/user_name/AppData/Local/Temp/tmpD616.tmp 0x200011b8 8
Error: 1492 5912 fileio.c:90 fileio_open_local(): couldn’t open C:/Users/user_name/AppData/Local/Temp/tmpD616.tmp

It could be a buggy antivirus, or non-English characters in the actual user name that you have edited out. Either way, please make sure you are using our OpenOCD fork. It includes a patch that uses a special command for batch memory operations instead of the slower “dump_image” one.

[support]

Hi,

Based on the screenshots you attached, this is an advanced ESP-IDF project. It is completely different from the MSBuild projects mentioned by the original poster in this thread, and indeed has different settings.

Please refer to the following page for detailed instructions on building it outside Visual Studio: https://visualgdb.com/documentation/espidf/#buildproblems

[support]

Hi,

Indeed, the STM32CubeIDE comes with its own fork of OpenOCD and slightly different scripts. You can install an equivalent of it by selecting OpenOCD (ST Fork) as the debug method instead of the regular OpenOCD. Please note that this requires VisualGDB 5.6 or later.

[support]

Hi,

Indeed, the .rsp files are generated after all variables have been expanded and contain very low-level instructions to GCC and other similar tools. The easiest work around it would be to use a simple custom script that will patch the paths inside the .rsp files when they are checked out under a different path. This should be still easier than setting up a complete development environment, including VS and VisualGDB on a docker container.

[support]

Thanks for renewing your license.

The page on the screenshot you attached is a completely different window from the Visual Studio project properties, and it indeed does not contain the project properties. Please see our MSBuild Documentation page for an explanation how to open the Visual Studio project properties and this section for a specific location of the “Generate a .bat file” setting.

[support]

Hi,

MSBuild indeed uses its own set of variables that work separately from VisualGDB variables. Due to the architecture of MSBuild, unfortunately it’s not possible to easily propagate all VisualGDB variables to the MSBuild level. As a workaround, please consider using MSBuild property sheets. They allow defining reusable variables and targets and importing them from one or more projects.

[support]

Hi,

The easiest way to do that would be to generate a .bat file for the MSBuild project on one of the development machines, check it into the source control, and run it on your Docker container. This way you won’t need to worry about installing Visual Studio, VisualGDB or any other tools under docker.

You can find more information about generating batch files for MSBuild projects here: https://visualgdb.com/documentation/projects/msbuild/#standalone

[support]

If you are using the same version of the tools and frameworks that are shown in our tutorial, it should work the same way.

If you are using a different version, it may indeed work differently, because it is a different version. We do not charge our users each time a new ESP-IDF framework is released, hence we are not able to guarantee that every ESP-IDF version will work exactly the same.

We do test the new releases and update our tutorials periodically, however we prioritize this based on the amount of affected users. The ESP-ADF framework is specific to audio devices, has a relatively small number of users, and is hence a lower priority.

[support]

Hi,

Please note that Espressif often changes the internal structure of their frameworks. They often break compatibility with older toolchains, or specific examples. Our support is not able to take over the maintenance and testing of their products, or provide personalized insights into their internal structure. We can only make sure that as long as the ESP-IDF-based project can be built and works otherwise, you will be able to use the VisualGDB GUI to conveniently edit it, instead of manually editing various configuration files.

If you are not able to build the project at all (even outside VisualGDB), please contact Espressif for further help.

[Author]

Posts