including startup_stm32*.c in project without absolute path

[bmcdonnell_psi]

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, 2 months ago by bmcdonnell_psi. Reason: typo

[bmcdonnell_psi]

I 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…

[support]

Hi,

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.

[the_steg]

Ok, 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.

 

[support]

This 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.

[Author]

Posts