Forum Replies Created
-
Posts
-
Hi,
Yes, if your embedded profile contains the <BSPSubdirectory> element (e.g. set to just “BSP”), the relative path for the peripheral register definition will be evaluated against the $(ProjectDir)\BSP.
Hi,
This might be related to the VisualGDB/VisualKernel interoperation. Do you have both of them installed? If not, does running VS elevated solve the problem?
Hi,
The “Go to definition” should only take some time on the first use after major project changes so that VisualGDB can update its cache. Perhaps you are changing some common include files that cause the cache to be invalidated?
If not, could you please open the Clang IntelliSense Diagnostics Console, clear its output, then run the Go-To-Definition command and send us the diagnostic output that is generated when you run it?
This is a known bug. Please try this build and let us know if the problem still reoccurs: http://sysprogs.com/files/tmp/VisualGDB-5.2.5.954.msi
Hi,
Currently not as it only affects the global settings (not per-project settings), so the change needs to be done only once. We will monitor the feedback on this and consider adding automatic settings conversion.
Hi,
VisualGDB 5.2 changed the internal settings engine to a new hierarchical one, so it will indeed not import some of the settings from the older version. However this will happen only once; after you change the settings again, VisualGDB 5.2 and all subsequent versions will use them.
Regarding the old projects, they got switched to Clang IntelliSense because the global “default engine” setting got reset to it. Please change it back via Tools->Options->VisualGDB and the projects will open under the VS IntelliSense again.
Hi,
The live watch/memory should work with OpenOCD and Segger J-Link. If you encounter any problems, feel free to let us know and we will help you solve them.
Hi,
Looks like VisualGDB is trying to link the original bootloader ELF file with the normal project. This should not happen with the latest VisualGDB 5.1r6. Either way, you can disable this by commenting out the following line in your main project’s Makefile:
LIBRARY_LDFLAGS += $(EXTERNAL_LIBS)
Note that the Makefile has several instances of this line for different project types.
Hi,
First of all, if you need to extend your trial, please simply contact our support via the contact form and they will give you a trial extension voucher.
Regarding the memory map, first of all can you try making a basic program that will turn some LED on to see whether the program ever gets executed correctly? If yes, the problem is related to debugging settings. If no, it’s related to compiling or linking.
You can indeed define the memory addresses for your code and data by creating a linker script file (you can search any of the VisualGDB BSPs for .lds files to get an example linker script) and then specify the path to it in VisualGDB Project Properties. The peripheral definition files are only used to visualize the peripheral registers and do not affect the functionality of your program.
You can also have a quick look at this tutorial if you have not done this already. It might explain some steps you could be missing.
The $(TOOLCHAIN_ROOT) is a new variable that is now automatically set to your toolchain location. You can still use the old ARM_TOOLCHAIN_ROOT variable if you want to use the toolchain relocation mechanism, but VisualGDB will automatically substitute $(TOOLCHAIN_ROOT) in directories reported by the toolchain.
Hi,
This is a known issue. Please try using VisualGDB 5.2 Preview 1. It contains an improved memory window that fixes this issue among other improvements.
Hi,
The easiest way to do that would be to use the Import Existing Project mode of the Linux Project Wizard. It will not automatically read the settings like CFLAGS, but will automatically add all source files from the specified directory. Then you can customize it further via VisualGDB Project Properties.
You can also try v5.2 Preview 1 that will automatically repair missing include paths once you open the source files that have some missing includes.
Hi,
This looks like a possible conflict between the 2 rule definitions (or explicit and implicit rule definitions). Could you post the entire Makefile here or search it for references to LCDConf.c and check if they match the actual file location?
Hi,
It’s still hard to say what exactly would be causing it. Normally the 2 line numbers reported by Make would point to the old and new definition, but in your example one of them points at an empty line (or a different Makefile). You can try commenting out the mentioned rule definition and running “make -d Release/Drivers.a” explicitly. If the build succeeds, examine the debug output generated by the -d option to see where else did it find the rule to build the file.
