Forum Replies Created
-
Posts
-
Hi,
It’s hard to say why the project has no BSPSubdirectory tag, but adding it should solve the problem.
The MCUDefinition location should not be related to the compiler location. Perhaps you have changed the toolchain location instead?
Hi,
Good to know it works. We actually have out-of-the-box support for embedded unit tests in VisualGDB 5.2 Preview1. You can read more about it here: https://sysprogs.com/w/the-new-unit-test-support-in-visualgdb-5-2/
Hi,
This depends on the exact library you want to integrate. For most cases it should be sufficient to just add their sources to your project and setup the include search paths so that the compiler can find the corresponding header files.
Hi,
Sorry for confusion. If you set the BSPSubdirectory field as described above, it will be using relative paths, e.g.
<BSPSubdirectory>BSP</BSPSubdirectory>...<MCUDefinitionFile>test.xml</MCUDefinitionFile>
Then VisualGDB will automatically use the <Project Directory>\BSP\test.xml path.
If you need a more specific example, we would recommend creating a normal BSP-based project, converting it to a stand-alone one and having a quick look into the generated mcu.xml file. It will not have any absolute paths hardcoded.
Hi,
Does ARM_TOOLCHAIN expand properly when you open cmd.exe and run “echo %ARM_TOOLCHAIN%”? If not, perhaps the toolchain is not configured as relocatable on that computer? You can mark it as relocatable via Tools->Embedded Tools Manager.
You can add the NRF52 macro directly to the Preprocessor Macros field on the Build Settings page. This will affect both building and IntelliSense.
Hi,
VisualGDB actually tests that the toolchain matches your target system by trying to build a simple application, uploading it and running it.
If you disable the option to test the toolchain in the wizard, you can skip specifying the connection.
It’s hard to say why from the log you have provided. If you encounter this problem again, feel free to share more details and we will try to help you.
Hi,
The command for setting memory breakpoints is the same as in normal Visual Studio – Debug->Windows->Breakpoints->New->Data Breakpoint.
We will add a context menu command for this in the Memory window in the final VisualGDB 5.2 release.
Hi,
From your log it looks like gdb stops at the “library loaded” event that is totally normal. Normally VisualGDB should detect those events and step over them automatically. What happens if you press F5 to continue debugging?
Hi,
The default VS IntelliSense won’t indeed pick up the VisualGDB variables like TOOLCHAIN_ROOT, however it should pick up the environment variables like ARM_TOOLCHAIN. If it does not, please open VS Project Properties, go to the NMake page, select “Include Search Path -> Edit” and then click “Macros” and check for the environment variables pointing to your toolchain directory.
Hi,
The VisualGDB SSH connections are stored in .sshconnection files in %APPDATA%\VisualGDB\SSHConnections. Could you check that the directory exists and is writable under your current user account?
The environment variables will only be picked up if you are using Clang IntelliSense. Are you using the default VS one?
Hi,
Sorry, we assumed that you have already converted the Makefile to work with Linux. If you only have a Windows NMake project, please try creating a Linux configuration for it by following this tutorial: http://visualgdb.com/tutorials/porting/linux/
Hi,
We have tried opening your project and could not reproduce the error. So it must be caused by something else (opening it from command line or some global setting you are using). We would be happy to pinpoint and resolve this, but we would need to know more about the circumstances of the error. It would definitely help us if you could try starting an empty VS instance and opening the project via File->Open->Project/Solution and let us know if the problem still persists.
