[support]

Hi,

Thanks, this looks like the hang happens outside the VisualGDB (or any other .Net-based components), which is strange as most GUI-related object in Visual Studio is based on .Net.

Please try attaching both ‘managed’ and ‘native’ modes and then recheck the main thread stack (you don’t need to attach other thread stacks as they are not related to the hang).

[support]

Hi,

There is no special GUI option for that, however you can accomplish it by adding “-Wl,-Bstatic -l<library name>” to the “Additional linker inputs” field. If this doesn’t work, please let us know your project type (MSBuild/Make/CMake/QMake) and we could suggest a better option.

[support]

Hi,

The IDF_PATH should actually be handled by VisualGDB directly. Normally it takes the list of IDF checkouts from the toolchain directory, however if you are keeping a custom checkout together with your codebase, we could add a per-user list of IDF checkouts. So once you configure (once per development machine) that the “com.yourcompany.idf-patched” is located in c:\projects\idf, VisualGDB will find it automatically from all projects.

[support]

Hi,

No problem. We will try to fit this in the next preview build of VisualGDB.

[support]

Hi,

This might be caused by some combination of your VS version, video driver and the display resolution (that would explain why it doesn’t trigger on our side).

We could add a setting that will limit the maximum amount of lines shown in the popups if this helps. However before that, please try attaching to the VS instance again and enable the “Show external code” option in the call stack. This should show what exactly the main thread is doing when VS is hanging.

[support]

Hi,

Currently we do not have plans for updating the Beaglebone tutorial as most of the steps shown in the current tutorial should still apply to the current version. That said, if you could let us know what exactly you found confusing/outdated, we should be able to update the tutorial to ensure it does not misdirect other readers.

Regarding the program location, by default, VisualGDB will upload all the sources to the specified location on the Beaglebone (the default path is /tmp/VisualGDB/…) and build it there. Normally the built executable would be located in the <uploaded source directory>/Debug or <uploaded source directory>/VisualGDB/Debug folder.

You can find out the exact path by starting a debug session and opening the GDB Session window in the All GDB Interaction mode. The first line should show the GDB command used to start debugging; this command should contain the full path to the built executable.

[support]

Hi,

Sorry for the inconvenience. This looks like something that was fixed in the recent Nordic BSP hotfix (14.2R2). Please ensure you install the latest version via Tools->VisualGDB->Manage VisualGDB Packages.

[support]

Hi,

We have quickly tried reproducing this, however unfortunately could not get anything similar. Could you please try attaching another VS instance to the hanging one (ensure Managed mode is enabled) and check the call stack of the main thread when it’s hanging? If it contains anything from the VisualGDB assemblies, please let us know the exact build number (from the About VisualGDB window).

[support]

Hi,

This might be tricky as the solution-level variables are not available to some parts of the build logic. Could you please clarify where exactly would you envision using this variable so that we could see if it could be supported?

[support]

Hi,

Thanks for the link. That version actually uses a completely custom makefile layout, so minor glitches are to be expected. If manually copying the file works, this is the recommended way to go around it.

Regarding HTML, we could add an option to show the contents of additional manually specified directories in Solution Explorer for ESP-IDF projects. Would that work for you?

[support]

Hi,

That should work as well. As long as the GNUTargetID is set properly, the toolchain ID and version can be set arbitrarily – VisualGDB will still recognize the toolchain properly.

[support]

Hi,

Yes, we always twit about new tutorials and blog posts. Please consider following us on Twitter to stay tuned.

[support]

Hi,

Sorry for the delay, the Espressif toolchain has a few rough corners we had to investigate before publishing the integration instructions.

First of all, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2263.msi

Then follow the instructions below to integrate the Espressif’s toolchain:

1. Unpack the toochain to an arbitrary directory on your machine and create a toolchain.xml file there with the following contents:

   <?xml version="1.0"?>
   <Toolchain xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <ToolchainName>ESP32</ToolchainName>
    <ToolchainType>Embedded</ToolchainType>
    <PathDetectionKeyStrip>0</PathDetectionKeyStrip>
    <GNUTargetID>xtensa-esp32-elf</GNUTargetID>
    <BuiltInBSPs>
    <string>esp32-bsp</string>
    </BuiltInBSPs>
    <ToolchainID>com.visualgdb.xtensa-esp32-elf.external</ToolchainID>
    <BinaryDirectory>opt\xtensa-esp32-elf\bin</BinaryDirectory>
    <Prefix>xtensa-esp32-elf-</Prefix>
    <Make>make.exe</Make>
    <IsCygwinBased>true</IsCygwinBased>
    <GCCVersion>5.2.0</GCCVersion>
    <GDBVersion>7.10</GDBVersion>
    <LIBCVersion></LIBCVersion>
    <BinutilsVersion>2.25</BinutilsVersion>
    <Revision>1</Revision>
    <MinimumEngineVersion>5.4</MinimumEngineVersion>
    <Comments>ESP-IDF 3.0</Comments>
   </Toolchain>

2. Copy the IDFCheckouts.xml file from our toolchain directory to the Espressif toolchain directory. This will ensure VisualGDB can find the esp-idf checkouts.
3. Copy the esp32-bsp directory from our toolchain to the Espressif toolchain directory. This will get the debugging plugin to be recognized.
4. Do not copy the esp-idf\v3.0 folder from our toolchain. Instead, create a recursive checkout of the Espressif repository manually using git from their toolchain. The 2 toolchains use different set of libraries and copying an existing checkout with prebuilt files will prevent the build from completing correctly. Also due to differences between the way git is installed in 2 toolchains, our ESP-IDF checkout manager won’t be able to use the git executable from the Espressif toolchain.
5. Open the ESP-IDF project wizard. On the toolchain page select “find a toolchain by locating gdb.exe”, then change the filter from “*gdb.exe” to “toolchain.xml” and point to the toolchain.xml file in your toolchain. This will add it to the VisualGDB toolchain list.
6. Create the project.
7. Open the VisualGDB Project Properties and change the path style from /cygdrive/xxx to MinGW (/c/xxx).

Now you should be able to build and debug the project as expected. Advanced functionality like opening the Cygwin shell might still not work though due to differences between toolchains.

Hope this helps. Let us know if you run into any problems or need further details.

[support]

Hi,

Sorry, we don’t have a specific deadline for this yet. The new SDK appears to merge the IoT functionality into the mainline SDK, so it might require extra effort on our side to ensure everything works smooth together. We will post an update on the forum once the new release is available though.

[support]

Hi,

Most likely this service was added after our major internal update, so it did not get picked up automatically by the BSP generator. As a workaround, please try adding the corresponding .c file to the project manually.

We might be able to address it in the upcoming SDK 15.0 update, although we cannot promise any specific deadlines for it yet.

[Author]

Posts