search

STMicroelectronics / STM32CubeL1

Full Firmware Package for the STM32L1 series: HAL+LL drivers, CMSIS, BSP, MW, plus a set of Projects (examples and demos) running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits).
Other
37 stars 24 forks source link

Preprocessor directives in "stm32l1xx_ll_spi.h" #13

Closed StressTest closed 2 years ago

StressTest commented 2 years ago

image

The code does not compile in Motorola mode. Or is it a bug in CMSIS? Because file stm32l100xb.h has no information about Bit4 FRF from SPICR2. (Missing lines #define SPI_CR2_FRF_Pos (4U)

define SPI_CR2_FRF_Msk (0x1UL << SPI_CR2_FRF_Pos) /!< 0x00000010 /

define SPI_CR2_FRF SPI_CR2_FRFMsk /!< Frame format /

) Description: https://community.st.com/s/question/0D53W00001FopFbSAJ/errors-in-the-configurator-of-the-stm32cubeide-for-microcontroller-stm32l100rb-not-observed-for-stm32f103-etc-low-layer-only

ASELSTM commented 2 years ago

Hi @StressTest,

As mentioned in the reference manual RM0038, the SPI_CR2_FRF bit represents the SPI TI mode which is only available in the category 3, category 4, category 5 and category 6 devices.

image

The devices categories are described in the "section 1.5 Product category definition" of the reference manual. The STM32L100RB is a category 1 device as mentioned in the table below .

image

Therefore, the SPI TI mode, and consequently the SPI_CR2_FRF bit, is not available in the STM32L100RB part number. Thus, there is no bug in the CMSIS file, the issue is rather related to the CubeMX generation problem as the code generated by CubeMx, is calling the LL_SPI_SetStandard function which is managed by the SPI_CR2_FRF bit.

Unfortunately, we don't treat aspect related to CubeMX tool in our GitHub repositories. They are rather treated at the STM32CubeMX dedicated page of the ST Community .

Please allow me then to close this thread. Thank you for your comprehension.

ASELSTM commented 2 years ago

ST Internal Reference: 120476