[support]

Hi,

This code looks totally OK from the gcc standpoint. If might not compile if the header defining U8 is not included, but otherwise it should work.

Please feel free to attach the exact error message you get so that we could give you better advice.

[support]

Hi,

If you are using the Custom edition, you can use the Build Customization page of VisualGDB Project Properties to add steps for deploying custom binaries after build (or Debug Customization page to deploy them before debugging).

[support]

Hi,

Thanks for the suggestion. We will monitor the future development of the TrueStudio and will consider importing projects from it if ST keeps on maintaining and supporting it.

[support]

Hi,

No problem, we have resent the confirmation email. Please check your inbox.

[support]

Hi,

Please let us know the email address associated with your license key so that we could check your support status.

[support]

Hi,

According to our records, the confirmation was sent to the email associated with your forum login. Please double-check your spam folder. As Avangate (our payment processor) has recently rebranded to 2Checkout, your previous email sorting rules may not work properly.

[support]

Hi,

It looks like your project relies on some functionality that is not present in our toolchain. The only known workaround to this would be to try downloading a toolchain from a different source (there are a few independent MinGW builds available online) or switching to Cygwin that is actively maintained, patched and is fully supported by VisualGDB.

[support]

Hi,

OK, no problem, if we could reproduce this, we should be able to fix it or suggest a better workaround. Please let us know if you are using MSBuild or GNU Make (if you could send us a sample project demonstrating the issue, it would be the best).

[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.

[Author]

Posts