Embedded framework, changing to external cube hal (STM32)

Sysprogs forums › Forums › VisualGDB › Embedded framework, changing to external cube hal (STM32)

Log In Register Lost Password
Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • July 16, 2016 at 20:03 #8561
    thm
    Participant

    In Project properties -> Embedded Frameworks I have STM32 USB, Cube HAL, etc. It would be nice to see the version number of these frameworks.
    It looks like they do not get updated until visualgdb decides to update them?

    I checked in C:\Users\username\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\STM32L4xxxx\STM32L4xx_HAL_Driver\ for example, the version is 1.2. Current version is 1.5.

    So here was my process to add the HAL externally, if anyone else wants to do the same:

    • Uncheck HAL from your embedded framework, HAL folders are removed automatically
    • Add preprocessor define for cpu: STM32L476xx=1
    • Include directories: /STM32Cube_FW_L4_V1.5.0/Drivers/STM32L4xx_HAL_Driver/Inc /STM32Cube_FW_L4_V1.5.0/Drivers/CMSIS/Include /STM32Cube_FW_L4_V1.5.0/Drivers/CMSIS/Device/ST/STM32L4xx/Include /STM32Cube_FW_L4_V1.5.0/Drivers/STM32L4xx_HAL_Driver/Inc/Legacy /STM32Cube_FW_L4_V1.5.0/Drivers/CMSIS/RTOS/Template
    • Include the .h and .c files in those folders in a new HAL folder in your project
    • Remove any template .c files from source, as you should have those functions defined already
    • Define APBPrescTable in system_stm32l4xx.c
    • Should build OK

    Maybe there is an easier way using import workspace, but didn’t try that (from say cube32mx).

    July 18, 2016 at 05:34 #8617
    support
    Keymaster

    We usually update our framework/BSP packages quarterly and are planning to update STM32 ones soon. The solution you described could indeed be used as a viable workaround.

    July 19, 2016 at 17:12 #8646
    bernardofca
    Participant

    Very useful post – thank you.

    I understand that vendors update their framework all the time but the STM32 issue is very annoying. As of today, CubeMX generates code for version 1.6 of the STM32F0 framework but VisualGDB has V1.3.0 (released June 2015). As a result, the code generated by CubeMX does not compile with VisualGDB.

    I also agree with the OP: it would be nice to be able to easily see the ST version of the individual frameworks.

    • This reply was modified 8 years, 3 months ago by bernardofca.
  • Author
    Posts
Log In Register Lost Password
Viewing 3 posts - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.