RM0385 has references to nonexistent GPIOx_BRR register.

[waclawek.jan]

RM0385 rev.8 has two references to nonexistent GPIOx_BRR register in the GPIOx chapter, even if there's no such register in the 'F7.

As changelog witnesses in v2 (under "Updated c7amba_ioport_UserSpec" :) ), there used to be a GPIOx_BRR description (presumably result of copy/paste from... 'F1?), so these are the unremoved remnants of it.

JW

[Danish1]

Hi Jan,

I assume this is really a complaint about updates in ST headers breaking other code and documentation also supplied by ST. I know you're extremely knowledgeable about ST microcontrollers, so I shouldn't need to point out to you that GPIOx->BRR is simply a 16-bit access to the high half-word of GPIOx->BSRR.

How to do it in C syntax? I'm not too sure, but I guess

GPIOA->BRR = 0x1234;

needs to become something like

((uint16_t *)&GPIOA->BSRR)[1] = 0x1234;

Regards,

Danish

[waclawek.jan]

Hi Danish,

Thanks for your comment.

I think I know what are you talking about: I do have this:

* @file    stm32f4xx.h
  * @author  MCD Application Team
  * @version V1.0.0
  * @date    30-September-2011
  * @brief   CMSIS Cortex-M4 Device Peripheral Access Layer Header File.
  *          This file contains all the peripheral register's definitions, bits
  *          definitions and memory mapping for STM32F4xx devices.
 
[...]
 
typedef struct
{
  __IO uint32_t MODER;    /*!< GPIO port mode register,               Address offset: 0x00      */
  __IO uint32_t OTYPER;   /*!< GPIO port output type register,        Address offset: 0x04      */
  __IO uint32_t OSPEEDR;  /*!< GPIO port output speed register,       Address offset: 0x08      */
  __IO uint32_t PUPDR;    /*!< GPIO port pull-up/pull-down register,  Address offset: 0x0C      */
  __IO uint32_t IDR;      /*!< GPIO port input data register,         Address offset: 0x10      */
  __IO uint32_t ODR;      /*!< GPIO port output data register,        Address offset: 0x14      */
  __IO uint16_t BSRRL;    /*!< GPIO port bit set/reset low register,  Address offset: 0x18      */
  __IO uint16_t BSRRH;    /*!< GPIO port bit set/reset high register, Address offset: 0x1A      */
  __IO uint32_t LCKR;     /*!< GPIO port configuration lock register, Address offset: 0x1C      */
  __IO uint32_t AFR[2];   /*!< GPIO alternate function registers,     Address offset: 0x20-0x24 */
} GPIO_TypeDef;

Splitting BSRR into BSRRH and BSRRL in the headers was a particularly dumb take from ST.

But BRR as a separate 32-bit register (where only LSB 16 bits are actually "active") is a real thing - look at the GPIO registers description of 'F1, 'F0, 'F3, 'L0, 'L4, 'G0, 'G4 RM, it's at offset 0x28 (while BSRR is at offset 0x18 - the offsets are different for 'F1 it is generally an exception to everything pin-related). It's also in *some* 'L1, but it's absent in 'F2/'F4/'F7 and 'H7.

I guess, the BSRRL/BSRRH dumbness was "inspired" by requests from users who were missing the BRR in 'F2/'F4 back then.

JW

[waclawek.jan]

Looking at that list of families containing BRR, above, it downed to me, that those, which do have BRR, use the single-port DMA, whereas those which don't, use the double-port DMA.

This should not matter, as GPIO registers can be written in word, half word or byte mode - except in 'F1, where GPIO registers are only word-writable, i.e. writing halfword into upper half of BSRR would result in writing the same value into both halfs (due the AHB/APB bridge's behaviour) which probably confused some of the early users - and then this probably stuck as a habit among the developers.

JW

[Sarra.S]

Hello @Community member​,

Thanks for reporting the issue.

I confirm this issue and I reported internally for correction in the coming release.

Internal ticket number: 138270 (This is an internal tracking number and is not accessible or usable by customers).

Sarra

[waclawek.jan]

Thanks Sarra!

Jan

@Sarra.S​