Forum Replies Created
-
Posts
-
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.
Hi,
The Makefile looks normal, so it’s hard to say what is causing this. Perhaps it has some strange inclusion loop and ends up included twice?
Can you try re-creating the project with the VisualGDB wizard and check if the warning re-appears?
Hi,
We are talking about this post. By deselecting the –begin-group and –end-group options you have made the linker sensitive to the order of the inputs. If you enable those options back, it should solve the problem.
Hi,
Normally VisualGDB uses the –begin-group/–end-group options exactly to avoid the need to specify the library order manually.
If you want to specify it manually and not use –begin-group/–end-group, you can do that by removing “winmm” from the “Library Names” field and manually putting the mix of “-lwinmm” and your .lib file in the correct order in the “Additional linker inputs” field.
Hi,
We are sorry that things don’t always work the way they are intended. We do have an extensive set of tests covering all major scenarios, but they do skip some rare cases like this one.
We do fix the reported issues very quickly though. This is already fixed in the daily build and will get into the next Preview of v5.2.
Hi,
We have just rechecked that and confirm that the namespace content indentation follows the generic “indent braces” setting. We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.5.954.msi
Hi,
Yes, if the $(file) command works properly for your make.exe, it is the preferred way.
Another alternative would be to use CMake (VisualGDB supports it for MinGW projects). We are also planning to add MSBuild support to VisualGDB 5.2 that will use the response files automatically.Hi,
Thanks, we have fixed this. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.5.952.msi
