Forum Replies Created
-
Posts
-
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.
Hi,
Sorry, not fully automatically yet. You can either re-create a project, or manually create a new platform “VisualGDB” via the Configuration manager and set the VS properties like .vgdbsettings file, toolchain, etc. manually. If you encounter any problems, feel free to let us know and we will provide help.
We will consider adding automatic conversion to v5.3.
Hi,
The easiest way would be to modify the Makefile to remove the references to EXTERNAL_LIBS so that the variable is simply ignored.
A better solution would be to try out the new MSBuild backend that comes with VisualGDB 5.2. It’s faster, more flexible and handles project references in a smarter way that does not break with non-default folder names.
Hi,
This is not possible directly, however you can simply remove the references to $(EXTERNAL_LIBS) in the Makefile rules. Hence VisualGDB will update the variable, but its value will be ignored.
Hi,
Sorry about this, it’s a separate problem actually. A quick workaround would be to manually change the colors for “Refactoring suggestion” via Tools->Options->Fonts and colors->Text Editor.
The upcoming Beta 4 will include automatic detection of the dark theme that will pick better default colors.
Hi,
The easiest way would be to copy it to the standard library directory on your target (e.g. /usr/lib), synchronize cross-toolchain sysroot (if you are using one) and just add the library name without the ‘lib’ prefix and ‘.so’ suffix to the “Library Names” field. Alternatively you could add the full path to the .so file to the “Additional Linker Inputs” field, but you would need to ensure that the relative path to the library during compilation matches the relative path during runtime (or use LD_LIBRARY_PATH to explicitly specify where to search for the libraries).
