[support]

Hi,

Sorry, the hardware registers window indeed only works when the target is stopped currently. We are planning to redesign it in the next major VisualGDB release, and this will also enable register updating while the target is running.

As a workaround, please try adding specific registers to Live Variables (the special Watch window that does get updated while the target is running). Let us know if you need more details on that and we will be happy to help.

[support]

Hi,

Could you have accidentally deleted the .vgdbsettings file mentioned in the error? Please try creating a new test project from scratch. Are you able to run the tests from it? Does switching the new project to the Release configuration (you would need to build the project after switching the configuration) result in an error again?

[support]

Hi,

It looks like your technical support has expired. Please renew it here and we will be happy to help you find the correct configuration.

[support]

Hi,

No problem. We have merged our patches into CMake 3.13.3 and updated our package. You can remove the %LOCALAPPDATA%\VisualGDB\CMake directory and restart Visual Studio. This should get CMake 3.13.3 installed instead of the previous version.

[support]

Sorry about that. Generally, based on our experience with Espressif’s tools, they are very sensitive to the specific toolchain/IDF versions. We had observed strange build-time and runtime errors after using a slightly different toolchain version that Espressif recommends, so we switched to picking up toolchain/IDF combinations recommended by Espressif, running minimal tests on them and shipping them in a way that can be seamlessly used with VisualGDB.

If Amazon is using a different version of the IDF, we would generally advise first importing it as an external embedded project with the toolchain tested by Amazon, using their OpenOCD build (manually configuring it via the “custom gdb stub”) and confirming that everything works. Then you could try replacing some of the components (e.g. OpenOCD) with the ones that come with VisualGDB.

We might be able to support this out-of-the-box once we see a considerable fraction of ESP32 users interested in this setup, however currently maintaining another stack of tools and a separate branch of the Advanced ESP-IDF Project Subsystem specifically for the Amazon FreeRTOS codebase is unfortunately more than we can offer, sorry.

[support]

Hi,

Thanks for the project link. It looks like the demo project is using a fairly old version of ESP-IDF that might not be compatible with the latest toolchain, or may not work reliably at all.

You can configure VisualGDB to use it by selecting the “import” option in the ESP-IDF selector on the first page of VisualGDB Project Properties. However, as it’s a relatively old ESP-IDF release, it may not work as expected and we would not advise doing that.

You can also import the project into VisualGDB as a regular external embedded project (see this tutorial). VisualGDB will then run the command line specified by you and will not make any assumptions about the project structure.

Generally, we would advise instead using the regular toolchain + ESP-IDF installed by VisualGDB and importing projects into this workflow. This will let you use the combinations of components that were tested together and will reduce the amount of errors you would have to resolve.

[support]

The Amazon FreeRTOS demo is likely ARM-specific, so you cannot directly import it “as is” into an ESP32-based project.

However you can create a regular project with ESP-IDF (see this tutorial) that will include a special port of FreeRTOS provided by Espressif. You can then call the regular FreeRTOS functions (same as called from the demo) from your main source file.

[support]

Hi,

ESP-IDF is already based on FreeRTOS, so no explicit action is required to use it – every project based on ESP-IDF includes a port of FreeRTOS.

[support]

Hi All,

The GCC itself it very stable (it’s used to build the Linux kernel that powers most of the servers nowadays), so the problem is likely caused by either your code or some libraries.

The only advice we could give is to try changing optimization level on specific files (it’s easy to do via VS Project Properties for MSBuild-based projects) in order to pinpoint the exact one. You can also try using the #pragma optimize to override optimization for specific functions (the #pragma will affect the rest of the source file unless you put another #pragma optimize there).

[support]

Hi,

Most likely this happens due to the missing mkfifo executable, or missing permissions. Please try running mkfifo /tmp/01d673d5-eb13-41d1-999a-8c7eda47ea45 manually via SSH to see why it fails. As soon as you fix the underlying issue, you should be able to run tests as usual.

[support]

Hi,

Normally, you should be able to reference the AAR library from another Android Studio project and then import the outer project into VisualGDB (see this tutorial). The classic VisualGDB projects (Ant-based) do not support AAR files as it is Android Studio-specific format.

We can help you import the Gradle-based project into VisualGDB, however that would require renewing your license to get the technical support active.

[support]

Thanks for the repro description. Indeed, our integration tests covered libraries and unit tests separately, but never tested them together, so we overlooked this scenario.

We have fixed the issue in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2743.msi

[support]

The issue is likely caused by some internal changes between different ESP-IDF versions. Normally doing a full rebuild should fix this (if you can confirm this, we can update VisualGDB to trigger a full rebuild automatically if the project was previously built with a different toolchain).

Please let us know whether a rebuild fixes the problem. If not, please also try creating a new project with the new toolchain and let us know if that works.

[support]

Unfortunately we are still not sure what you meant. The logic for importing the macros is the same for both compilers.

If you are still trying to solve the original problem with the CRYP definition, please check the  stm32_*_config.h file as suggested earlier. Depending on your project configuration, you may need to enable the CRYP module on the Keil Packages page of VisualGDB Project Properties (available in the Custom edition or higher).

If this is not what you are looking for, please let us know exactly the problem you are trying to solve.

[support]

No problem. For Make you could try doing the same manually (extract the gcc command line from the logs and then replace -c with -E and .o with .E and run it), but ultimately it may not be worth the effort.

[Author]

Posts