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

GPIOx BRR registers incorrectly defined #8

Closed abelNoelleC closed 3 years ago

abelNoelleC commented 3 years ago

Bug observed during use of the STM32Cube HAL, imported/used in Zephyr OS.

During my own testing I've observed that for the following SoCs it has been defined that BRR registers are available, even though this isn't the case (according to the reference manual).

In the SoC headers (e.g. in Zephyr: modules/hal/stm32/stm32cube/stm32l1xx/soc/stm32l100xc.h) #define GPIO_BRR_BR_0 (0x00000001U) has been defined, which has an influence on LL_GPIO_ResetOutputPin() in stm32l1xx/drivers/include/stm32l1xx_ll_gpio.h, which has the following condition:

#if defined(GPIO_BRR_BR_0)
  WRITE_REG(GPIOx->BRR, PinMask);
#else
  WRITE_REG(GPIOx->BSRR, (PinMask << 16));
#endif /* GPIO_BRR_BR_0 */

This causes the behaviour that if one would like to put a GPIO pin to 0, the SoC can't write to the proper registers (BSRR), because GPIO_BRR_BR_0 has been defined, even though the SoCs don't have the BRR register.

In the reference manual [click] pg 188 it says that the BRR registers are only available on Cat 4-6 devices. On pg 41 it shows that the SoCs listed above (L1xxxC) are Cat 3.

Please fix asap, since it can have a large impact on the GPIO functionalities of these SoCs

RKOUSTM commented 3 years ago

Hi @abelNoelleC,

Thank you for reporting this point. Actually, the point you raised has also been discussed internally since a while, before we receive your request. The issue you reported has been already fixed in the frame of version v1.10.0 (CMSIS Device v2.3.1) of the STM32CubeL1 published on GitHub.

Thank you again for having reported.

With regards,

RKOUSTM commented 3 years ago

ST Internal Reference: 45853