STM32L476 No GPIO->AFRL OR ->AFRH

[john doe]

Posted on August 02, 2017 at 01:35

Reference manual RM0351 STM32L4xx, section 8.4.9 and 8.4.10 GPIO registers AFRL and AFRH are not defined in the stm32l4xx.h file, except as   __IO uint32_t AFR[2];      /*!< GPIO alternate function registers,     Address offset: 0x20-0x24 */

so building will fail because GPIOx->AFRL or GPIOx->AFRH are not defined. GPIOx->AFR[0] gives me the low and ->AFR[1] gives me the high.

[Tesla DeLorean]

Posted on August 02, 2017 at 03:49

You understand that the AFR[2] representation makes the C code and application of these registers more efficient?

[john doe]

Posted on August 02, 2017 at 03:58

I figured that out after the fact. I'm just trying to dump registers so I can learn why my stuff doesn't work. I always feel that I'm reinventing the wheel here.

GPIOA->MODER:   0xABFFB7AE    10101011111111111011011110101110

  PIN  0: Alternate function mode

  PIN  1: Analog mode (reset state)

  PIN  2: Alternate function mode

  PIN  3: Alternate function mode

  PIN  4: Analog mode (reset state)

  PIN  5: GPO mode

  PIN  6: Analog mode (reset state)

  PIN  7: Alternate function mode

  PIN  8: Analog mode (reset state)

  PIN  9: Analog mode (reset state)

  PIN 10: Analog mode (reset state)

  PIN 11: Analog mode (reset state)

  PIN 12: Analog mode (reset state)

  PIN 13: Alternate function mode

  PIN 14: Alternate function mode

  PIN 15: Alternate function mode

GPIOA->AFR[0]:  0x20007701    00100000000000000111011100000001

  PIN  0: AF1

  PIN  1: AF0

  PIN  2: AF7

  PIN  3: AF7

  PIN  4: AF0

  PIN  5: AF0

  PIN  6: AF0

  PIN  7: AF2

GPIOA->AFR[1]:  0x00000000    00000000000000000000000000000000

  PIN  8: AF0

  PIN  9: AF0

  PIN 10: AF0

  PIN 11: AF0

  PIN 12: AF0

  PIN 13: AF0

  PIN 14: AF0

  PIN 15: AF0

I'm trying to figure out why pwm input capture isn't triggering an interrupt and your advice is always read the registers. At this point im just fleshing out what the registers mean, for GPIO and TIM so far.

I'm probably the only idiot doing things this way, otherwise there'd be some kind of tool for this in the Cube repository...right(??)

[waclawek.jan]

Posted on August 02, 2017 at 10:48

GPIOx->AFRL or GPIOx->AFRH are not defined

Good point IMO. I got used to it over the years, but you are perfectly right: the headers should 100% reflect the manual and vice versa.

I have this same problem with how BSRx is treated in the headers.

I'm probably the only idiot doing things this way,

I use the debugger for the same purpose, watching and manipulating directly the peripherals' registers, but it's a fact that it can be intrusive.

Your method is being employed for ages, both as ad-hoc in-program debugging tool and in monitors, which sort of fell out of fashion when the cheapo debuggers working with on-chip debugging facilities came in.

JW