[support]

Hi,

Normally the command should work (unless you enter it in the “additional gdb commands” and your debug preferences override it). Either way, the recommended way of handling this is using the “Interrupts” window of VisualGDB (click the lightning icon in the GDB Session window). VisualGDB will let you modify signal handling from there and will also remember the settings for the next debug session.

[support]

Hi,

Please update to the latest VisualGDB 5.3R7. The problem is fixed in that version.

[support]

Hi,

This is explained in step 22 of the tutorial. Please follow the instructions shown in step 23 (the debug settings page will look slightly different due to a recent update to our OpenOCD debug method).

[support]

Hi,

Normally you should be able to do it by following the esp8266 gdb stub tutorial. If it doesn’t work, please let us know if the programming stage succeeds (progress bar showing programmed addresses) or whether the device never enters the bootloader mode.

[support]

Hi,

This looks like an invalid path specified in one of the commands, rather than an incompatibility with mbed. We would advise double-checking every modification to Makefile you made just before this problem started occurring. If you are not sure, please try following the tutorial from the beginning and double-checking that the projects build successfully after each step. Once you locate the step that breaks the build, please double-check the edits made in this step.

If you don’t understand the meaning or role of some edits/custom commands, let us know and we will update the tutorial explaining them in more detail.

[support]

Hi,

Thanks for your feedback. We are currently researching possible approaches for Arduino integration and the ability to import existing community libraries sounds like a useful feature.

[support]

Hi,

The multiple nested breakpoints occur when one line of source code corresponds to multiple addresses (and hence needs multiple physical breakpoints). The usually happens with inlined functions or templates (e.g. list<int>::sort() vs list<string>::sort()).

It is hard to say why would this make VS hang. One guess would be that gdb needs to update too many physical breakpoints each time you stop the session and this takes time. You can try running the “set breakpoint always-inserted on” command to prevent gdb from updating breakpoints each time the session stops.

If this doesn’t help, we would recommend narrowing it down to a specific breakpoint (e.g. measuring break-in delay with and without it) and checking if this can also be reproduced without VisualGDB. If not, some gdb options or initialization commands could be affecting it. If yes, it’s likely a limitation of gdb and not much could be done to work around it other than generally speeding up connection to your target.

[support]

Hi,

This looks like VisualGDB mistakenly assumes that those files belong to a VisualGDB-managed project. Please try the following:

1. Close your solution.
2. Clear the Clang diagnostic log.
3. Reopen the solution and open one source file. Ensure the problem persists.
4. Post the entire Clang log here. It should explain what projects are considered open by the IntelliSense and why it attaches to your files.

Also as a quick workaround while diagnosing this you can change the default engine on the Clang IntelliSense Diagnostic Console to “VS IntelliSense” while not working with VisualGDB projects. This should prevent it from attaching to the files unless the project referencing them explicitly enables Clang IntelliSense via settings.

[support]

Hi,

The window displays various service information that is required for us to check whether VisualGDB is initialized correctly. We also could not find any orders associated with your email address. Please let us know the address associated with your license.

[support]

Hi,

Thanks, we have tried reproducing this with your template file, but unfortunately could not get anything similar. Most likely the problem is caused by some combination of installed/referenced toolchain versions. If this is too annoying, we can add extra diagnostic logging to the logic responsible for the toolchain selection, so it will explain what is causing this with your setup. Let us know if you would like to try it out.

[support]

Hi,

No problem. In case anyone else reads this topic, the global setting defines the subdirectory name for the IntelliSense Code Database, the base directory is controlled by the SysprogsCodeDBDirectoryBase variable. I.e. the full path to the directory is $(SysprogsCodeDBDirectoryBase)\<Subdirectory name in global settings>.

Unless your project explicitly defines SysprogsCodeDBDirectoryBase, it defaults to $(OutDir).

[support]

Hi,

Thanks for the update. We would still need to see the About window to check the initialization status of various VisualGDB components.

[support]

Hi,

Sorry, for remotely build MSBuild projects the output directory must be located inside the directory of the project so that VisualGDB can map the file paths between the Linux and Windows machines.

You can still move the CodeDB directory outside the project directory by adding the following lines to your .vcxproj file:

<PropertyGroup>
    <SysprogsCodeDBDirectoryBase>$(SolutionDir)..\path-to-directory</SysprogsCodeDBDirectoryBase>
</PropertyGroup>

[support]

Hi,

The error means that the remote host rejected the file upload request via SCP. This might happen if the folder permissions are not configured properly or if the SSH server is not configured to accept uploads.

We would recommend checking the syslog on the Linux machine for more details on the error and updating your SSH server if nothing helps.

[support]

Hi,

No problem, we will provide detailed answers to your questions below:

1. You can configure VisualGDB to install multiple versions of mbed as follows:
   1. Open Tools->VisualGDB->Manage VisualGDB Packages
   2. Locate “ARM mbed”
   3. Enable the “Allow installing multiple versions of this BSP”
   4. Click “Online” in the left part of the window
   5. Enable the “Show old versions” checkbox at the bottom of the window
   6. Filter for “arm mbed”
   7. Install the previous versions you need

   When you create an mbed-based project next time, VisualGDB will allow selecting a specific version to use; when a new version is available, VisualGDB will install it side-by-side with the current one and will let you switch it via VisualGDB Project Properties.

2. VisualGDB expects gcc to be configured to load the correct specs automatically, however you can easily change this by editing the toolchain.xml file in the toolchain directory (VisualGDB creates it when importing a toolchain). Although the file format is not officially documented, looking through the toolchain.xml file in our ARM toolchain should easily explain where VisualGDB takes references to options like nano.specs and let you adjust it. Also if you have any questions about the toolchain.xml file structure, let us know and we will be happy to provide more details.
3. This looks like some path transformation issue between GNU Make and the toolchain. One quick fix could be to use the make.exe shipped with your toolchain instead of the one shipped with VisualGDB. If this doesn’t help, please try the steps below:
   1. Run the “C:/SysGCC/EmBitz/1.11/bin/arm-none-eabi-g++.exe …” command line directly from the project directory. Does this result in the same error?
   2. If not, please try adding “-d -d -d” to the Make arguments (or just running “make -d -d -d CONFIG=Debug” in the VisualGDB project folder) to dump diagnostic output from Make. This should show which command it is trying to run just before the error happens. Ensure that running the command manually reproduces the problem.
   3. Try removing various parts of the command line to see which one is responsible for the error (e.g. try removing all the “-IC:/…” arguments).
   4. If your toolchain doesn’t accept the “-IC:/” syntax, try using the “-I/c/path” and “-I/cygdrive/c/path” syntax. If you find a syntax that works, let us know and we will help you configure VisualGDB to use it.
4. We normally recommend using MSBuild for all new projects. MSBuild provides much better level of integration into Visual Studio than Make and can also be used on your build server as shown in this tutorial. Hence it is not possible to directly convert MSBuild projects to GNU Make. You can add a “Win32” platform manually and copy the .vgdbsettings, Makefile, .mak and mbed.xml files manually from a different project, but you would need to copy various build settings manually.
5. The memory usage is only shown if VisualGDB is using the Embedded Make or MSBuild subsystems. They are recommended for embedded projects, as many features like Embedded Frameworks, profiler, etc rely on VisualGDB’s ability to recognize and automatically change project settings (e.g. reference new libraries). If you would like to use the “imported 3rd-party Makefile” mode instead, we can easily enable memory usage reporting for it, but other features relying on automatic settings updating still won’t work.
6. Looks like you have already found the option for this.
7. It is possible to add 3rd-party debug methods to VisualGDB using 2 mechanisms:
   1. If you want to continue using OpenOCD, you can add a new .cfg file and then update the edp.xml and QuickSetup/interfaces.xml files to make VisualGDB recognize your device and select the script automatically.
   2. If you want to use a 3rd-party gdb stub, you can define the command-line arguments for it via a custom edp.xml file as shown in this tutorial. You can also create full-featured debug plugins with custom settings GUI and custom FLASH programming steps (e.g. see this one), although those interfaces are not officially supported. I.e. we can point you to the right direction if you get stuck, but we cannot provide detailed step-by-step instructions for every possible customization and we may change some of the interfaces in the future versions.

Let us know if you need any further information and we will be happy to help.

[Author]

Posts