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

[support]

Hi,

Please try creating a new MSBuild-based project, keeping the default value of Code Database Folder Name and setting the “Output Directory” field to the following:

$(SolutionDir)..\test\$(Platform)$(Configuration)

Then reopen the solution. The CodeDB directory should be created under the ..\test directory. If this doesn’t help, please let us know where exactly it is created. If this helps, please compare this setting to the setting in your project and adjust your project accordingly.

[support]

Hi,

Looks like the VisualGDB debug engine might not be initialized properly. Could you please share a screenshot of your About VisualGDB window?

[support]

Hi,

Thanks, we have rechecked this. The latest update to the STM32Cube SDKs renamed the sample configuration files for FatFS, assuming that you would rename and copy them to the project directory manually, so the checkboxes indeed don’t work anymore (they only work for including files from BSP). We have updated BSP rules to remove them (will take effect in the next BSP update). We have also removed the BSP directory with ffconf.h from the include directory list to avoid confusion between the 2 files.

As a workaround, please locate the matching template files (e.g. FatFS\src\drivers\sd_diskio_template.*), copy them to the project directory and add them to Solution Explorer.

The native VS IntelliSense is known to hardcode several macros and VS-specific features; our best advice is to use the Clang IntelliSense that is specifically designed to work around this type of issues.

[support]

Hi,

You can change the location of the CodeDB folder as follows:

Tools->Options->Text Editor->C/C++ (VisualGDB)->Indexing->Code Database Folder Name

The output directory (e.g. VisualGDB\Debug) can be changed via regular Visual Studio project properties (first page) for MSBuild projects and via VisualGDB Project Properties for other project types.

[support]

Hi,

We are planning to roll out Android CMake support around the beginning of the next year. As a temporary workaround, we can publish a version addressing the build issues (but not including the 2-way CMake integration yet) in 2-3 weeks. Let us know if you would like to try it out.

[support]

Hi,

Looks like your STM32 BSP is incomplete. Please try reinstalling it via Tools->VisualGDB->Manage VisualGDB Packages.

[support]

Hi,

This could be the case if the 3rd-party code you are trying to import was not compatible with GCC (the compiler used by VisualGDB that is different from the online mbed compiler). The “conflicting return type” error usually points to several locations where a method is defined/declared (implying that those locations have different return type specification). We would advise double-checking those locations (e.g. one of them might be after including a header file that redefines off_t). You can also use the “generate preprocessor output” option in VS File Properties to get the fully preprocessed output of the corresponding source files (that will expand all #define and #include directives making it easier to understand cryptic error messages).

[support]

Hi,

This doesn’t look like a message produced by VisualGDB. Our latest mbed package is based on mbed 5.6.3, so most likely the message comes from some missing configuration variables. We would advise trying to locate the code producing the message and adjusting it accordingly.

[support]

Hi,

We are sorry for the inconvenience. Unfortunately Apple is known for not maintaining backward compatibility for 3rd-party tools like gdb, so we cannot promise that gdb won’t be broken by a recent update to any other OS X version. We would advise trying Mac OS 10.12 Sierra (as long as you can debug your program with gdb via command line, VisualGDB should support it as well).

[support]

Hi,

Please try setting the VS Project Properties -> ARM Settings -> Floating-point unit type.

You can read more about various FPU options supported by GCC here: https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

[support]

Hi,

Sorry for the delayed reply. We have tried reproducing this with different toolchains and device settings, but could not get any similar behavior. Please ensure that you are using the latest VisualGDB 5.3R6. Please also feel free to share your template file with us. As it looks like a VisualGDB bug, we will be happy to fix it if we can reproduce the problem on our side.

[support]

Hi,

The VM error shown in the log is actually a known Java issue and can be easily solved via environment: https://stackoverflow.com/questions/18040361/java-could-not-reserve-enough-space-for-object-heap-error

Regarding Gradle support, the latest Gradle switched the build system from ndk-build to CMake, breaking backward compatibility. The latest version of VisualGDB has introduced a new Advanced CMake subsystem (currently supported for Linux and Embedded projects only) that replaces the regular Visual C++ logic for CMake-based projects and we are planning to extend it with support for Android projects in the next major VisualGDB release.

Currently we recommend installing an SDK version that supports ndk-build (importing Gradle projects from Android Studio is supported). Once we release a VisualGDB preview supporting CMake on Android, the CMake-based projects will start working out-of-the-box as well.

 

[support]

Hi,

We have just rechecked everything on the latest MacOS High Sierra and could not reproduce the problem with the gcc specs. The project got created fully automatically, although debugging was not possible because MacOS High Sierra does not have a compatible gdb build yet.

We would advise trying an earlier MacOS build and also updating to VisualGDB 5.3R6 (looks like you are using the previous v5.2).

[Author]

Posts