GPIOx BRR registers incorrectly defined

[abelNoelleC]

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).

• stm32l100xc
• stm32l152xc
• stm32l151xc
• stm32l151xca
• stm32l162xc
• stm32l162xca

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]

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]

ST Internal Reference: 45853