[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

[support]

Hi,

VisualGDB uses the AutoDownloadedFiles folder for sources on the remote machine that were are not covered by path mappings known to VisualGDB (e.g. if your code uses a library with debug sources in /usr/src/<something>). Based on your description, VisualGDB cannot automatically detect that Windows folder that corresponds to the remote Linux folder, so it tries to download the files. This could be fixed very easily by adding a manual mapping on the Path Mapping page of VisualGDB Project Properties.

[support]

Hi,

The behavior you are describing happens in the “Allow choosing build/clean/debug command hosts independently” checkbox on the Project Settings page is not set. Please double-check that you actually set it. If this does not help, please send us your .vgdbsettings file so that we could check what is going on.

[support]

Hi,

Thanks for the link. The module looks interesting, but it’s currently very new and it’s hard to say how much demand it will get. We will continue monitoring its popularity and if it starts getting traction, we will add a BSP for it.

[support]

Hi,

VisualGDB indeed does not have a dedicated template for static Embedded libraries and will generate the usual LEDBlink code.

It will still be a library project, so if you simple replace the generated code with your library functions and reference the library from your main project, it should work.

[Author]

Posts