- This topic has 2 replies, 3 voices, and was last updated 8 years, 5 months ago by
.
-
Posts
-
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).
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.
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.
- You must be logged in to reply to this topic.