[support]

Hi,

It should be turned on automatically. Perhaps something is preventing VisualGDB from recognizing the STL containers properly? Please try switching the GDB Session window to the “All GDB interaction” mode and then clearing its output and viewing one of the variables. Then please post the commands shown in the GDB Session window here. This should help us understand why the visualizers are not turning on.

[support]

Hi,

Yes, this is true. The actual problem with clang is reliability. It does not look like the community actively uses Clang (not commercial Clang-based compilers, but Clang itself) for barebone ARM devices, so publishing a toolchain based on it will most likely result in discovering ARM-specific bugs and issues, so we will have to either start fixing Clang bugs or have a toolchain on our website that has known usability issues and is disappointing to use. Both options are not very good, so at this point we do not want to ship such a toolchain.

That said, you are free to experiment with the Clang binaries from the Clang website (we can help you configure VisualGDB to use them), but if they generate broken code, or don’t work as expected, we cannot provide any support on that, sorry.

[support]

Hi,

Thanks for explaining this. Most likely you used a wrong linker script with the converted project. The LinkerScripts\nRFxxxx_s130.lds references the softdevice so that it is included in your project.

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

[Author]

Posts