Built-in BSP with custom BSP_ROOT

Sysprogs forums Forums VisualGDB Built-in BSP with custom BSP_ROOT

This topic contains 5 replies, has 2 voices, and was last updated by  support 2 months, 1 week ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #859

    bojanpotocnik
    Participant

    Hello!

    1) I created my custom Toolchain, at first it said “Compatible device definitions: 0” but then (after few days) somehow managed to “copy” device support from built-in Sysprog’s Toolchain and now I have the same device support. This is not the problem – actually, this is good feature which I welcome. But, how do you decide which devices are supported?
    [attachment=1:f6tg8v3q]Screenshot 2014-10-15 08.08.40.png[/attachment:f6tg8v3q]

    2) When I create the project, I can select my device (STM32F303VC) or provide the Makefile flags manually. I choose integrated support and select STM32F303VC because I like all the settings VisualGDB defines and provides in file:

    But the problem is that I don’t want to use provided driver files which are included in stm32.mak in project folder:

    because I have my own drivers and files created with STM32CubeMX. If I edit stm32.mak file, it gets overwritten. I can “backup” the variables before include $(ADDITIONAL_MAKE_FILES) and then restore them, but I think this is not practical.
    I created additional project with custom flags and looked at its MCU.xml for BspID tag and then modified stm32.xml in mi original project from:

    to

    which only provided error when opening project settings ūüôĀ
    [attachment=0:f6tg8v3q]Screenshot 2014-10-15 08.39.53.png[/attachment:f6tg8v3q]

    It’s is possible to add some checkbox or XML settings to initially configure project with integrated settings and flags, but later “deatch” it from BSP?

    3) Is it possible to add checkbox something like “Use relative paths”? Because now I am using Python script in makefiles to convert all possible paths to relative, as example:

    if I don’t do that, Rebuild is impossible because of error “Multiple make rules” in .dep files (colons in absolute paths are recognized as separate Make rules).

    4) Makefile -> Build tools -> Make command. What is the difference between default:
    cmd.exe /c “C:cygwinbinmake.exe”
    and
    C:cygwinbinmake.exe or just make, because I have Cygwin added to my %PATH%. Both are working, why CMD?

    Best regards,
    Bojan

    #3264

    support
    Keymaster

    Hi,

    We have added support for ‘detaching’ projects from BSPs to the upcoming VisualGDB 4.3.
    Please switch to a newer version of GNU Make. The one that comes with our toolchains supports the c:/xxx path syntax in .dep files properly.
    Running make.exe without cmd used to cause some random crashes in some cases. We did not investigate this further, as it looks like a bug specific to some versions of GNU Make for Windows and using cmd fixes it.

    #3263

    bojanpotocnik
    Participant

    Thank you for your answer.

    Approximately when will new version be released or is there any option for “Beta updates”? ūüėõ

    I am using latest make, but it’s true that I use none of the tools provided with VisualGDB but Cygwin instead

    I will try using your make instead. Thank you.

    #3262

    support
    Keymaster

    Hi,

    You can update for free to any version released within a year from your purchase date (we usually count the date of the first beta). Hence you can start using the beta now and simply install the final release over it once it’s out.

    Cygwin build of make is the root cause of the problems you are expecting. It expects the paths in the /cygdrive/c/xxx format, while our toolchains are MinGW-based and report paths in the c:/xxx format. To avoid further problems, ensure that your toolchain and your make executable are built for the same platform.

    #12365

    bojanpotocnik
    Participant

    After a few hours of trying and Google-ing I stumbled upon my own topic again. However, now I am using nRF52832 and MSBuild build system (VisualGDB 5.3 Preview 8). I created the embedded project with specifying build flags manually, which is OK. But in this case I have a problem that there is no Makefiles, only MCU.xml,  $(ProjectName)-$(Configuration).vgdbsettings and $(ProjectDir)mcu.props files. If I add a new variable e.g. NRF5_SDK_ROOT in the User variables  section of the VisualGDB Project Properties and then use it in the paths under Embedded Project as $(NRF5_SDK_ROOT)\... it does not work, the variable is always empty.
    How does one use variables with MSBuild system?

    And about¬†Embedded Project and¬†MSBuild settings sections in the¬†VisualGDB Project Properties – when are those set of settings synchronized (it seems like they’re not at all)? Which e.g.¬†Include directories should I edit?

    Thank you.

    #12370

    support
    Keymaster

    Hi,

    In order to add MSBuild variables, you would need to edit the .vxcproj file as follows:

    The settings from Embedded Project page get written to the mcu.props file after you change them (VS would not display those in VS project properties) and apply to all configurations inside a project.

    The settings from the MSBuild settings page get saved in the .vcxproj file and are applied to each configuration independently.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.