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

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

[Author]

Posts