Forum Replies Created
-
Posts
-
Hi,
We do have a tutorial for that: http://visualgdb.com/tutorials/arm/standalone/
Hi,
Looks like Make is having trouble launching make2728-1.bat. This does not look like anything generated by our Makefiles, so please check that you have enough free space on the disk and check the full build log to understand which part of the build process produces this.
Hi,
If your program never goes beyond that line, it means that your PLL never gets a stable frequency output. This may happen if the PLL multiplier/divider settings are incorrect for your board (e.g. the project you are building is meant for a different board with a different clock crystal).
Hi,
Sorry about that, we are not aware of this issue, but will be happy to help you pinpoint it. Do you get a message like “gdb command xxx is taking too long” in the GDB Session window while VisualGDB locks? If no, is the Visual Studio GUI responsive, or does it totally hang? If it hangs, does killing CppEngineHost.exe via Task Manager unfreeze it?
Hi,
First of all, we recommend using MSBuild instead of GNU Make as it is more flexible and requires less workarounds on the VisualGDB side.
If you want to use Makefiles nonetheless, please add a dependency and then rebuild the solution. Do you see both projects being build in the correct order? If no, please attach the build output here. If yes, please let us know what does not work.
Hi,
You can tweak the Clang IntelliSense behavior by adding Clang-friendly command-line flags to “Additional flags for C/C++ files” fields on that page (e.g. -DSOME_MACRO). The IntelliSense is actually using Clang, so all Clang flags that are relevant for source parsing should be supported. If you are looking for a specific setting, let us know and we will suggest a flag that controls it.
Hi,
Yes, you can fully customize the embedded project templates, device definitions, etc. VisualGDB stores them in XML files under %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs. While the format is not documented or officially supported, we try to make it as self-documenting as possible and if you encounter any questions with it, feel free to ask for advice and we will point you to the right direction. You can also look through the sources of the tools that generate BSPs for the families supported by VisualGDB – they are available on our Github repo: https://github.com/sysprogs/BSPTools/
Regarding the peripheral library, you can simply convert your project to a stand-alone one and VisualGDB will copy all the necessary files for you.
Regarding the toolchain, we want to minimize the amount of maintenance (and possible bugs) with the toolchain, so we ship one toolchain for all supported ARM cores. Deleting the cortex_a directories should not interfere with cortex_m compilation, so feel free to repackage the “lite” version of the toolchain for your own use or share it with the community. Just please change the toolchain ID in toolchain.xml to avoid confusion with the original toolchain if you want to redistribute it.
Hi,
Yes, the embedded frameworks look correct. The nRF5x.xml file should be located in your project directory. If you are not sure about it, the EmbeddedProfile element in your .vgdbsettings file should contain the relative path to that file:
<EmbeddedProfileFile>MCU.xml</EmbeddedProfileFile>
Hi,
Sorry, something things are buggy. We do have plans for a better file synchronization engine that will detect such cases, but it’s hard to say whether it makes it to v5.3, as it is a fairly complex feature and such bugs are relatively rare.
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.
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.
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.
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.
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.
