Sysprogs forums › Forums › VisualGDB › including startup_stm32*.c in project without absolute path
Tagged: project startup linker warning
- This topic has 4 replies, 3 voices, and was last updated 4 years, 2 months ago by support.
-
AuthorPosts
-
February 1, 2017 at 22:42 #10276bmcdonnell_psiParticipant
I have a VisualGDB STM32 embedded project based on code generated by STM32CubeMX. I’m including the Cube libraries in source control for the project.
There is one particular source file that is named in the project file (.vcxproj) with an absolute path that contains my username:
..\..\..\..\..\Users\[myname]\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\STM32F0xxxx\StartupFiles\startup_stm32f072xb.c
Obviously this isn’t portable…
Bad solutions:
- Copying it to the source folder means I’d miss out on library updates.
- Excluding the file from the build produces the following linker error:
c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-eabi/6.2.0/../../../../arm-eabi/bin/ld.exe : warning : cannot find entry symbol Reset_Handler; defaulting to 08000000
What’s the right solution here? Can I use a macro or something to make it point to something like this?
[eabi_location]\com.sysprogs.arm.stm32\STM32F0xxxx\StartupFiles\startup_stm32f072xb.c
Here are some of my project settings, for reference.
- This topic was modified 7 years, 9 months ago by bmcdonnell_psi. Reason: typo
February 1, 2017 at 22:53 #10278bmcdonnell_psiParticipantI see that
VisualGDB Project Properties -> Embedded Project tab -> Regenerate MCU files
re-includes it in the project, using the same absolute path.
What’s the recommended workflow with this? As is, it seems to me that it’ll break for every new user that checks it out of source control, until they click Regenerate themselves. And then multiple users working on the project simultaneously will have to maintain different versions of the project file…
February 2, 2017 at 06:25 #10280supportKeymasterHi,
Unfortunately the Visual Studio extensibility API cannot handle variables in .cpp file paths properly, so VisualGDB has to use relative paths with the user name.
It will automatically update those paths if you open the project on a different machine where the paths are different. Another option would be to relocate the BSP to a location under the source control (see this tutorial). Then VisualGDB will use relative path to that location.
September 2, 2020 at 04:02 #28960the_stegParticipantOk, this is an old thread but….
Why does the imported GPDSC project not use the startup file provided by cubemx (Drivers\CMSIS\Device\ST\startup_stm32blahxx.s)? I can’t really work out why the vgdb .c one is used when the library lives in the project directory and the project uses the system_stm32 in that directory.
September 2, 2020 at 06:32 #28962supportKeymasterThis is by design and comes from the VisualGDB general project structure. The VisualGDB startup file is functionally equivalent to the ST startup file and should work just fine.
-
AuthorPosts
- You must be logged in to reply to this topic.