including startup_stm32*.c in project without absolute path

Sysprogs forums Forums VisualGDB including startup_stm32*.c in project without absolute path

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #10276
    bmcdonnell_psi
    Participant

    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
    #10278
    bmcdonnell_psi
    Participant

    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…

    #10280
    support
    Keymaster

    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.

    #28960
    the_steg
    Participant

    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.

     

    #28962
    support
    Keymaster

    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.

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.