Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
Good to know it works now. BTW, we have recently released a new toolchain with an updated gdb that should be a bit more stable.
April 8, 2016 at 03:14 in reply to: Sharing *.vgdbsettings between projects, inheriting path from *.vsprops #7921support
KeymasterCool. Thanks for sharing this.
support
KeymasterHi,
We could easily add variables like $(BuildUserName) and $(BuildHostName) and similar ones for deployment machine. Would that be helpful?
support
KeymasterHi,
The problem with raw telnet is that it does not support easy file transfer and has no convenient API for running just one command and seeing when it exited. It could be achieved via various workarounds, but they won’t be very reliable.
We currently recommend setting up a custom project and simply adding custom pre-debug commands to transfer your files to the device. Similarly, you can use the expect tool to connect to the target via raw telnet and specify it as the local GDB executable so that VisualGDB will simply launch it and send the commands there.
We will monitor the demand for this feature and consider adding it if the demand grows. In the meanwhile, feel free to try the workaround described above and if it does not work, we will gladly provide more detailed steps.
support
KeymasterHi,
You can easily remove all extra files from the project by unreferencing the HAL library in VisualGDB Project Properties -> Embedded Frameworks.
support
KeymasterHi,
The file you posted is has different _estack and memory size than we suggested. Please double-check that you are using the values we suggested above.
support
KeymasterHi,
Normally yes. When you add a reference from one Makefile project to another one, VisualGDB will add the outputs of referenced projects to the EXTERNAL_LIBS variable in the Makefile (updated on each build) and the libraries will be linked with.
support
KeymasterHi,
As long as you don’t have more parallel activations of VisualGDB than your license allows and don’t move the VMs between physical machines too often, you’re fine both legally and technically.
support
KeymasterHi,
It looks like there is a bug in our LPC1768 linker script that results in incorrect memory size definition.
Please open VisualGDB Project Properties on the Makefile Settings page, click “Create local copy” near the “Linker Script” field. Then open the linker script added to the project and edit it as follows:
MEMORY { FLASH (RX) : ORIGIN = 0x00000000, LENGTH = 512K SRAM (RWX) : ORIGIN = 0x10000000, LENGTH = 48K } _estack = 0x1000C000;
support
KeymasterNo problem. If you encounter further problems, feel free to create another topic.
April 6, 2016 at 02:06 in reply to: Sharing *.vgdbsettings between projects, inheriting path from *.vsprops #7896support
KeymasterHi,
Sure, we could easily add something like this. Could you send us a sample project file with your rule layout so that we could test it?
BTW, if you are using your own build system and don’t need VisualGDB to update Makefiles, you can simply replace the build command with <VisualGDB.exe> /build <file.vgdbsettings>. This will eliminate the need to parse the .vcxproj files.
April 5, 2016 at 19:31 in reply to: Sharing *.vgdbsettings between projects, inheriting path from *.vsprops #7892support
KeymasterHi,
The problem happens because VisualGDB needs to parse the .vcxproj file when building the project and it does not have the VS API available at that point, so it does not check included property sheets. Hence each project needs to specify the path to the settings file explicitly. Also due to the performance limitations of VS, the settings file name needs to be named exactly as <Project>-<Configuration>.vgdbsettings file, as otherwise some of the context menu GUI won’t be able to find it.
The easiest workaround would be to symlink the files via the mklink commands. We could also add a feature to allow linking property files, e.g. each of your project’s .vgdbsettings files could contain something like <LinkedFilePath>$(BUILD_ROOT_DIR)\…</LinkedFilePath> and then VisualGDB would load the linked file instead of the per-project files. Would that work for you?
support
KeymasterOK, perhaps the “CPU did not halt” error is unrelated to the Default_Handler() problem.
Please try adding ‘DEBUG_DEFAULT_INTERRUPT_HANDLERS’ to the Preprocessor Macros field on the Makefile Settings page of VisualGDB Project Properties and build your project again. This should show which actual interrupt ends up being unhandled.
April 5, 2016 at 19:20 in reply to: Clang IntelliSense not working with Raspberry Pi OpenCVDemo #7890support
KeymasterHi,
Are you talking about the IntelliSense when editing the OpenCV sources, or when editing your application based on OpenCV?
Please ensure that the “Configure IntelliSense baesd on CFLAGS dumped by CMake” checkbox on the CMake Project Settings page is set. If it was not set, please set it and build your project again.
support
KeymasterHi,
This error happens when VisualGDB fails to update your system environment properly. Normally restarting your computer should help.
-
AuthorPosts