Adding embedded frameworks leads to build errors

Sysprogs forums Forums VisualGDB Adding embedded frameworks leads to build errors

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #21918
    regus_pregus
    Participant

    Environment: VisualGDB 5.4 (preview 4, build 2394) with VS Community Edition 2017 (15.8.2)

    Target: STM32F746NG (on STM32F746G-DISCOVERY board)

    Problem summary: adding embedded frameworks to the project leads to multiple compile errors.

    Steps to reproduce:

    1. Run VS with VisualGDB installed
    2. Create new project (File->New->Project->VisualGBB->Embedded Project Wizard)
      1. Project type page: Create a new project with = MSBuild, Embedded binary (.elf) = check, Additional output binaries: bin = check, leave all other settings default
      2. Device selection page: STM32F746NG, Execute from = FLASH, Exclude the startup file from project = UNCHECK, leave all other settings default
      3. Sample selection page: STM32 CubeMX Samples tab, select FreeRTOS_DelayUntil sample project, leave all other settings default
      4. Debug method page: Debug using = OpenOCD, JTAG/SWD programmer = ST-Link v2.1, Program FLASH memory = Always, leave all other settings default
    3. Build the project (Build->Build solution) – builds without errors
    4. Add some frameworks
      1. Right-click on the project root in Solutions Explorer, select VisualGDB Project Properties menu item
      2. Select Embedded Frameworks tab on the left of the VisualGDB Project Properties window
      3. Check STM32F746G-Discovery drivers item
      4. Message: “The following frameworks are required: STM32F7Cube HAL”, press Yes
      5. Check SDRAM drivers in STM32F746G-Discovery drivers list
      6. Press OK
    5. Build the project (Build->Build solution). Multiple linker script warnings and compile errors will result.

    In general, I am observing similar behavior in various combinations of initial projects and frameworks being added. For instance, you also get build errors when you start with a LTDC_PicturesFromSDCard sample as a project base and attempt to add FreeRTOS embedded framework later. In general, the whole mechanism of adding frameworks to the existing code is not very usable now, and without it, there is no really a convenient way to add functionality to your project.

    On a related question, right now when creating new ARM projects, there is no option to start with a “barebone” project, you need to select one of the sample projects that already has some functionality in it. Maybe it would be better to have an empty project template as a starting point (only basic processor/board config and empty main() function) and then have the “adding frameworks” functionality that really works with that empty project and other frameworks being added?

     

     

    #21924
    support
    Keymaster

    Hi,

    Sorry, that’s unfortunately by design. Each embedded framework managed by VisualGDB includes all of the source files from the corresponding directory. The ST samples (selected as “STM32CubeMX Samples” on the sample page) often include a subset of the sources from a particular framework that is used in this particular sample. This makes them incompatible with the framework mechanism out-of-the-box.

    We generally recommend using the vendor samples (e.g. STM32CubeMX samples) to quickly explore various drivers and libraries that come with the SDK and then creating production projects based on the regular samples that are compatible with the framework system. Alternatively you can simply reference the necessary frameworks and manually remove the conflicting files from the regular source file list.

    We don’t do the adjustment automatically as a part of our BSP generation, as we want the vendor samples to be 100% equivalent to the original ST projects they are based on in order to minimize the chance of introducing errors. Unfortunately this means inheriting the monolithic non-modular structure of the original projects.

    Hope this explains. We can also share more detail on the inner workings if the samples, BSPs and frameworks, so you would tweak them to your needs.

    With the barebone project, there could be several variants of it for different cases (e.g. with different linker scripts/startup files/system files), so instead of providing a separate barebone sample, we recommend using the VisualGDB project template mechanism. Simply start with the LEDBlink project, remove all code and the unnecessary frameworks and then export it as a VisualGDB template via the File menu. Next time pick “create a project from template” and VisualGDB will automatically copy the project structure. You can also tweak the template files after creating them, as they are simply ZIP files with an XML index + the referenced source files.

     

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