[support]

Hi,

Thanks for the detailed description, it indeed explains what is going on, so we will try to suggest a good workaround.

The advanced ESP-IDF subsystem works by running the ESP-IDF build command in a special “dry run” mode where it simply prints the gcc command lines that would be used during the build (it still generates config files and a few others). This works for the regular ESP-IDF projects, however it appears to be breaking the custom component you imported.

The easiest fix would be to simply copy the mkespfsimage binary from the actual build directory to the equivalent path under VisualGDBCache/EmbeddedProject12-Debug/CodeSenseDir and then reload the project. It should unblock the ESP-IDF build logic and VisualGDB will be able to pick up the project structure from it. Another option would be to remove the ‘-n -k’ arguments from the build command line you mentioned and rerun it manually. This should build the necessary files automatically and let VisualGDB load the project.

Also if you could point us to the specific version of the library that is causing the issue, we might be able to add a better workaround.

[support]

Hi,

Yes, we are planning to release another toolchain update as we are adding support for the new CMake-based ESP-IDF. If the “-mfix-esp32-psram-cache-issue” is included in the mainline ESP32 toolchain sources, it will get automatically picked up during the update.

We can also help you integrate the original ESP32 toolchain into VisualGDB if you could let us know the email associated with your license key so that we could verify your support status.

[support]

Sorry, the AssignProcessToJobObject error looks like something happening inside the toolchain’s gdb and it outside VisualGDB’s control, so the only way to diagnose it would be to check with the toolchain vendor. Other than that, importing of 3rd-party toolchains via the CustomToolchain mechanism is fully supported.

We are not aware of the bug with switching the toolchains; if you decide to renew your support, please let us know how to reproduce it and we will investigate/fix it.

[support]

Hi,

Building with VS should actually work (as in produce the relevant error message). The ESP-IDF projects work differently from the regular VS projects – instead of storing a redundant copy of the project structure in the .vcxproj file, they query the up-to-date structure directly from ESP-IDF and render it in the Solution Explorer. Hence if the ESP-IDF is not able to configure and produce a list of the built files, VisualGDB won’t be able to show anything in Solution Explorer, although it will still be able to kick off the build command.

Once you resolve the build errors (just the ones in the build scripts, errors in source files won’t affect anything), VisualGDB will load the project structure and let you use the convenient GUI to manage it.

[support]

Hi,

Yes, most likely something goes wrong with the build scripts. Please try building the project and check the build log – it should show what exactly is stopping the ESP-IDF build system from proceeding.

[support]

Hi,

Thanks for the repro case. It looks like VisualGDB is incorrectly picking up the indentation of the “width(width), height(height) {” line as a base instead of the “ImageRef( uint32_t fmt_4cc,” line. We are currently experimenting with switching our indentation engine to clang-format (that will also let you reuse the clang-format settings files), so this will likely resolve the issue once the switch is complete.

If we decide to delay the switch to one of the next VisualGDB releases, we will improve our current indentation logic to locate the start of the statement properly.

[support]

Hi,

It looks like you have enabled the 32-bit mode for compilation, but not for linking. Please ensure that -m32 flag is set in both compiler and linker flags.

[support]

Hi,

The missing hardware registers is a known issue – our mbed BSP generator uses very basic logic to associate mbed targets with register files provided by other BSPs and doesn’t pick up the ARCH_MAX properly. The workaround is very easy – just select the correct definition file from the Hardware Registers window.

Regarding clocking, it looks like your technical support as expired. Please renew your license and we can help you understand the mechanism used by mbed to control the STM32 settings and change them.

[support]

Hi,

This looks consistent with your settings – the namespace contents are not indented, the class contents are. If you could narrow this down to some specific steps that lead to undesired behavior, we should be able to diagnose/fix this. Otherwise it is hard to see what exactly could be causing the trouble.

[support]

Hi,

If you are trying to reserve a fixed amount of space for the stack/heap, please try adding the “Fixed stack/heap” framework via VisualGDB Project Properties -> Embedded Frameworks and VisualGDB will do this for you automatically.

Otherwise you would need to edit the linker script to modify the memory layout manually. You can simply copy the default linker script used by VisualGDB locally via VisualGDB Project Properties -> Build Settings, move the .reserved_for_stack section to the location you want and update the _estack symbol to be defined at the end of the .reserved_for_stack section (the initialization code will use this symbol to set the initial stack address).

[support]

Hi,

Yes, we are expecting to release the next preview with Arduino support in the next 1-2 weeks.

If you buy a license now, you will be able to use any VisualGDB version released within 1 year from your purchase. This will definitely include v5.4 that is currently in preview and might include the next major release, depending on the exact release schedule.

[support]

Hi,

Yes, we will consider doing that if ST continues actively developing/supporting TrueStudio.

Either way, we have made our project importing plugins open-source to help our users import formats that are not directly supported by VisualGDB yet. This way you might be able to create a basic importing plugin that will automate most of the work you need before we officially support it.

[support]

Hi,

Normally it should work automatically if you are using the latest VisualGDB 5.4 Preview 3, however setting it manually is a reasonable workaround if it doesn’t.

If you can confirm that the setting is not automatically picked up with the latest VisualGDB, please feel free to post a repro project here and we will investigate/fix this.

[support]

Hi,

It will basically restrict discovery of references to the main source file only. E.g. if you have a template function inside the main file, but it’s instantiated somewhere in a header file, that instantiation will be ignored and the function body won’t be colored properly (that only affects template functions and only if they are not used inside the main file itself).

It might also interfere with the ‘find all references’ functionality for translation unit-scoped entities (e.g. static functions), that are declared inside the main file, but used from headers (this won’t affect finding references for regular functions/classes, as it involves scanning the entire project using a different mechanism that is not affected by this setting).

[support]

Hi,

Thanks, this looks like a known issue. Please try clicking on the timer icon in the upper right corner of the document and click “enable lightweight references” (or enable it via VisualGDB Project Properties -> IntelliSense). This should significantly reduce the parse time.

 

[Author]

Posts