[support]

Hi,

Can you confirm that creating the directory fixes the command-line build? If yes, we will simply add automatic directory creation to the corresponding MSBuild task.

[support]

Hi,

Yes, this file contains ARM-specific compiler settings and is normally generated by VisualGDB first time you use the toolchain. If you building the code on another machine, we recommend copying the entire toolchain directory as is, or simply creating a new project with that toolchain using the VisualGDB project wizard and it will regenerate all necessary files.

[support]

Hi,

VisualGDB provides its own mechanism for visualizing STL containers and supports Visual Studio natvis files, so you actually don’t need the Python scripting to debug them.

[support]

Hi,

The FastUpToDateChecks.targets file actually manages the creation of the alldeps file, not the actual checks.

Could you try manually creating the directory where the .alldeps file is stored (from the error message)? Perhaps some combination of settings is preventing the directory from being created? If this is the case, we can easily fix this.

[support]

Hi,

Thanks for the build output. It looks like the linker script from mbed expects the SystemInit() function and the other functions to fit in 512 bytes:

        KEEP(*(.isr_vector))
        *(.text.Reset_Handler)
        *(.text.SystemInit)
        
        /* Only vectors and code running at reset are safe to be in first 512
           bytes since RAM can be mapped into this area for RAM based interrupt
           vectors. */
        . = 0x00000200;

Please change the optimization setting for the system_LPC11Uxx.c file to “Minimize size” via normal File Properties in VS (you need to be using the new MSBuild subsystem to set per-file settings).

[support]

Hi,

Thanks, looks like the /usr/include/c++/4.8/x86_64-suse-linux/32 path on your Linux machine is a circular symlink. Please try removing it and sync the directories again.

[support]

Hi,

Strange, the linker script setting should have been converted automatically. Are you using a custom linker script or the default one provided by VisualGDB? Is your project using mbed or the regular nRF5x SDK?

[support]

Hi,

Are you sure you have removed the reference to the HAL framework on the Embedded Frameworks page of VisualGDB Project Properties?

If yes, please send us your .vxcproj and the nrf5x.xml file so that we could check this.

[support]

Hi,

The only files VisualGDB will use from APPDATA in this case would be the startup file and the linker script as they should be compatible with all versions of HAL.

If this is not acceptable, you can also create the project by selecting “Enter flags manually” in the wizard and entering the preprocessor macros, includes and linker script manually and then adding the HAL files to the project. This will produce the same result as converting the project to a stand-alone one automatically.

[support]

Hi,

There might be a command line switch or a “monitor” command in the Segger GDB stub for that. Please double-check that with Segger support.

[support]

Hi,

If you are using the Custom edition of VisualGDB, it can do this automatically for you if you convert the project to a stand-alone one via VisualGDB Project Properties. You could also just relocate the BSP files into a location under source control so that they will be shared between several projects.

If you are using a lower edition, you can remove the reference to the STM32 HAL framework via VisualGDB Project Properties and add the source files from CubeMX manually.

[support]

Hi,

Thanks, looks like your settings have one minor inconsistency. We have provided further details per email.

[support]

Hi,

This error indicates linker error and the Output window should contain more details about it. Most likely your linker script is corrupt or the program is too big to fit in the memory. In the latter case please select the newlib-nano library via VisualGDB Project Properties and try enabling the -Og optimization in the Visual Studio project properties (this is the optimization level that should not interfere with mots of the debugging features).

[support]

Hi,

No problem. BTW, if you want to add more text to the previous post instead of creating another one, you can use the ‘edit’ link.

Regarding the extra windows, most likely there is still some small mismatch between the paths. Please right-click on the tab header and select “Copy full path” for both tabs and compare the paths side-by-side in an editor.

Regarding Clang IntelliSense errors, again it is most likely caused by some small typos in include paths. We would recommend using VisualGDB 5.2 that will show a special hint if an include file is missing and will help you locating it via the Browse button and will then adjust the IntelliSense settings. If this does not help, please let us know the details on the errors you are observing and we will help you diagnose them.

[support]

Hi,

This means that your Linux machine is not running the OpenSSH server. If you are using a Debian-based distro, you can install it via the following command:

sudo apt-get install openssh-server

[Author]

Posts