Forum Replies Created
-
Posts
-
Hi,
This happens because the gcc used in the Beaglebone toolchain is too old and does not support C++11.
Our toolchains exactly match the gcc version used natively on the board. We are planning to recheck the gcc version in the latest Beaglebone images and release an updated toolchain in the next 2-3 weeks.
Hi,
Thanks very much for reporting this. Apparently there was a bug in our MSBuild backend that caused problems with Nordic projects.
Please try this build, it includes a fix for this: http://sysprogs.com/files/tmp/VisualGDB-5.2.12.1281.msi
Hi,
We have just published a tutorial showing how to use the header discovery: http://visualgdb.com/tutorials/intellisense/headers/
If this does not help, please attach a screenshot of your Visual Studio showing the Errors pane and the text editor for the source file that has the missing headers.
Please note that the new feature only works if you are using the Clang IntelliSense.
Hi,
Thanks for the log. It looks like you have modified the main source file and then tried reparsing one of the header files. This does look like a bottleneck and we could optimize this further.
Can you confirm that code completion within the main .cpp file works reasonably fast after the trick with explicitly ending the preamble?
Hi,
The include directories are handled separately from the .h files in Solution Explorer.
The easiest way to resolve this is to update to VisualGDB 5.2 Beta 4 and let it find the missing header files automatically.
Hi,
Thanks for clarifying this. Normally the FLASH programming is handled by OpenOCD, so supporting special programming modes would involve creating an OpenOCD patch.
As this feature looks like something very specific to certain bootloader types, we would not be able to give it enough priority to push it into one of the next releases. Sorry about that.
Our best advice would be to submit a feature request to the OpenOCD community.
Hi,
No, Live Profiling uses the regular SWD/JTAG lines and does not require any extra connections. It relies on the fact that you can read/write target memory over JTAG/SWD without stopping the target and uses a simple memory buffer for communication.
Hi,
Resharper uses a separate IntelliSense engine, so unless JetBrains explicitly adds support for parsing VisualGDB projects, it may not work properly.
We do recommend using our Clang IntelliSense engine for VisualGDB projects as it is especially optimized for GCC-specific code and provides many improvements compared to the regular Visual C++ IntelliSense.
If you miss some of the features with it, please let us know and we will consider adding them.
Hi,
Thanks, we have located and fixed the problem. It was caused by a conflict between an internal target called ‘build’ and build.c in your project. Please try this build: VisualGDB-5.2.12.1269.msi
OK, we have added support for this to VisualGDB 5.2 Beta 4.
You can find a detailed tutorial here: http://visualgdb.com/tutorials/linux/win10/
Hi,
No problem. Could you provide an example of the copy-modify-writeback function you mentioned? Do you mean software breakpoints in FLASH memory?
Hi,
This looks like a known bug of Resharper. Please try disabling it and ensure that you have Visual C++ installed.
Hi,
Sorry, looks like you are using v5.1. Please try the latest v5.2 beta. It uses separate internal environments to handle the long reparse and critical operations like code completion, so it should be much faster.
Hi,
If the bootloader expects the non-bootloader code to be placed at a specific address (e.g. 0x8005000), the easiest way to achieve this is to add a line like this before the corresponding section in your linker script:
. = <offset to place subsequent code/data>
You can double-check the addresses of the code and variables by enabling the map file generation and looking through the map file once the build is done.
