[support]

Hi,

The easiest way to get it working would be to download our Raspberry Pi toolchain and use its toolchain.xml file as a template. The format is pretty self-descriptive: you specify a unique ID, name, paths to various tools, and VisualGDB will run them when building the projects. Fields like tool versions are optional and are used to show meaningful summary in the toolchain selector. Fields related to SD card and target version checks can be removed.

Once you have edited toolchain.xml, you can place it into the FreeBSD toolchain directory, click “locate a new toolchain” in the VisualGDB’s toolchain selector, and point it to the new toolchain.xml file. If you edit the file VisualGDB imported the toolchain, you can open and immediately close Tools->VisualGDB->Manage VisualGDB Packages to reload all changes.

As for LLDB, VisualGDB can automatically detect gdb/lldb based on its reply to “info version”, so you can simply put your lldb executable in the toolchain’s bin folder and add the following line to toolchain.xml:

<GDB>lldb.exe</GDB>

This will override the default name of gdb derived from the <Prefix> field.

If the new lldb binary still doesn’t work, you can try checking the Debug->Windows->GDB Session window in the Raw GDB Output mode. It shows all commands executed by VisualGDB, and their replies. If you can point out specific commands that are not being issued as expected (e.g. require some special flags), we should be able to adjust VisualGDB to accordingly as long as you can confirm that running the updated command manually works as expected.

[support]

Hi,

We merely repackage the toolchain that comes from ARM. If you would like us to do a custom build for you, feel free to contact our sales for a quote.

[support]

Hi,

The linker itself is a 32-bit executable, so it has a 2GB memory limit rather than 64GB.

VisualGDB itself does not do anything special that would affect the memory usage by the linker. It merely launches Ninja, that in turn launches GCC/ld. If it works from developer power shell and doesn’t work with VisualGDB, you can troubleshoot it as follows:

1. Run both builds in verbose mode to obtain the exact linker command lines.
2. Try manually running both command lines from a separate command prompt.
3. If you can reproduce the behavior (one command line triggers the problem, while the other one doesn’t), try comparing the command lines and editing them to gradually remove the differences, until you narrow down a specific option that triggers the problem.

 

[support]

Hi,

It looks like your antivirus hooks the Visual Studio process (possibly, to scan the downloaded file), and than encounters some kind of a internal error. The easiest way around it would be to add Visual Studio to the exception list.

The manual installation should normally work. If it doesn’t, please share the exact URL of the file you are trying to install, and we will recheck it.

[support]

Hi,

Thanks for reporting this. VisualGDB was indeed using a fixed “,” separator when generating CSV files.

We have updated it to use the same system-level setting that Excel does, and also added a manual override option (Tools->Options->VisualGDB->General->Files->CSV file separator).

Feel free to try this build: VisualGDB-6.0.101.5155.msi​

 

[support]

Hi,

If the linker did not generate the ELF file, there isn’t anything for VisualGDB to analyze. You can try patching the linker script to temporarily increase the RAM size so that the linker won’t fail, and then use Embedded Memory Explorer.

[support]

Hi,

It looks like you have specified invalid settings at some point. Unfortunately, it’s impossible to suggest anything meaningful without knowing what exact settings you have used.

Please try creating a new project from scratch, ensure that it builds, and then try changing one setting at a time until the problem triggers. Once you can reproduce it, please share a screenshot of the exact setting you changed and we will try to suggest a workaround.

[support]

Hi,

Normally the first header file should just include the second one. As long as both header files have a #pragma once, it should work just fine.

Another option would be to explicitly open the header file in a context of a .c/.cpp file that includes both of them in the correct order. You can do it via the navigation bar in the new VisualGDB 6.0.

[support]

Hi,

The actual FLASH programming logic is defined by the underlying SDK or Arduino platform. VisualGDB merely runs the programming command line defined by it.

If you can program FLASH from some other IDE or via command line without pressing the button, it could be a VisualGDB bug (e.g. some command-line option gets lost). If not, it’s a limitation of the platform you are using.

[support]

Hi,

If you suspect this is a bug of VisualGDB, you can try uninstalling the latest version and installing an older one here. If this fixes the problem, please let us know the version that works vs. the version that doesn’t.

If this doesn’t help, please try creating a new project from scratch and check if it works. If yes, you can try comparing the project files between the 2 projects. One of the settings that is different is likely causing the issue.

[support]

According to our records, we have replied to your inquiry with the details on the academic license purchase.

[support]

Hi,

This issue is different from the other thread (hence, we moved it to a separate one) and comes down to a bug in the ESP-IDF selector. After updating the toolchain and refusing to download the old (incompatible) ESP-IDF, VisualGDB should normally have shown the old ESP-IDF version in Project Properties, letting you select the new one, but it was instead showing just the new one, despite still referencing the old version.

We have fixed the issue in this build: VisualGDB-6.0.101.5152.msi​. It actually includes 3 fixes:

• Suggests updating ESP-IDF reference to the one shipped with the new toolchain
• If refused, allows switching it manually via GUI
• When changed, clears the temporary files next time the project is loaded or built

[support]

Hi,

This looks like an incompatibility between valgrind and your kernel and not something directly caused by VisualGDB.

As far as our support goes, we can explain how VisualGDB launches valgrind and what modes it uses, however we would require an active license for that.

[support]

No problem. Please let us know the email address associated with your license so that we could link it to your support profile.

[support]

Hi,

Please do not manually copy any directories without understanding what causes the underlying problem. This only entangles the issue further and makes it harder to troubleshoot.

You can try exporting the ESP-IDF configuration command used by VisualGDB to a batch file as shown here. If the batch file shows incorrect IDF_PYTHON_ENV_PATH value, please let us know and we will look into it.

If the value looks correct, and ESP-IDF still doesn’t work, it could be a bug in ESP-IDF. Please consider reporting it to Espressif. If they suggest a configuration command line that fixes the problem, we can help you configure VisualGDB to use it instead.

[Author]

Posts