Forum Replies Created
-
Posts
-
Hi,
Good to know it works. BTW VisualGDB has a ‘breakpoint diagnostics’ button in the GDB Session window that should detect and fix problems like this automatically. If you ever run into this again, the breakpoint diagnostics can save you some time…
Hi,
The arm-eabi toolchain does not actually expect an operating system; it’s designed to work with barebone projects (or using RTOSes like FreeRTOS).
Thanks for clarifying that you have specified the FP option manually. Then the problem could be caused by incompatible settings entered somewhere. If you can reproduce this on a new project, could you archive it and send it to us? We should be able to locate the problem quickly for you.
The ‘get settings from Makefile’ button does a very basic scan of the Makefile for lines like “CFLAGS := xxx”. It is very basic and does not handle complex cases as there is no good way of importing those settings from large projects reliably.
Hi,
Normally VisualGDB tries to import all C++ formatting settings from regluar VS. Because those vary between different VS versions, the importing logic is quite complex and may have bugs. If you could give us an example of a specific setting that is not imported properly, we should be able to fix it.
Hi,
The 4.8.3 toolchain indeed looks quite old. Furthermore, the problem might be caused by an incompatible default VFP setting in your toolchain.
VisualGDB actually comes with a newer one (can be installed from the wizard of from here), so we would recommend using it instead.
Hi,
You can always upgrade to the Custom edition by following this link: http://sysprogs.com/splm/mykey
Hi,
We would recommend using the External Memories feature of VisualGDB 5.1 for that (required Custom edition or higher). It will manage the linker scripts for you automatically and should avoid such problems.
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.
