Forum Replies Created
-
Posts
-
The ‘end’ symbol is used to specify the beginning of heap, so defining it after SDRAM will break the malloc() functionality.
Hence we would recommend defining ‘end’ so that it actually points at the end of data in RAM.
Hi,
Yes, as long as you are using the Custom edition or higher, you can describe your SDRAM on the External Memories page of VisualGDB Project Properties as described here and VisualGDB will show its utilization automatically.
Hi,
Please try the new v5.2 Preview 2. It contains a workaround against this and also adds a context menu to the memory window to create data breakpoints.
Hi,
Looks like your cocos package was not downloaded properly. Please try removing and reinstalling it.
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.
