get address of every register(?)

[hossein hosseini]

Posted on October 10, 2017 at 09:46

hi.i want to get address of every register on stm32 , and set value to register but i dont  know what is address of register so how can i get the address of register?

for example if i want to get address of  RCC_CFGR  what do i do ??

thanks.

#register #address

[waclawek.jan]

Posted on October 10, 2017 at 10:12

They are in the CMSIS-mandated device headers.

Cube user? For example, for 'F4, look into [STM32Cube_FW_F4_V1.16.0]\Drivers\CMSIS\Device\ST\STM32F4xx\Include\

Other families in similarly sounding places.

JW

[Alan Chambers]

Posted on October 10, 2017 at 10:52

What

Waclawek.Jan

said, except that the headers define structures representing groups of registers. These are overlaid on specific hardware base addresses. For example, search for RCC_TypeDef:

typedef struct

{

__IO uint32_t CR;

__IO uint32_t PLLCFGR;

__IO uint32_t CFGR;

... // Lots more registers

} RCC_TypeDef;

#define RCC ((RCC_TypeDef*)RCC_BASE) // Macro RCC_BASE resolves to a 32-bit address.

In your code:

RCC->CFGR = ...

I would rely on these structures rather than the actual numerical addresses as they may not be portable.

[Tesla DeLorean]

Posted on October 10, 2017 at 12:07

Why? There are a huge number of them,  this isn't an 8051.

The addresses are described in the manuals, the header files, etc.

One can also use the ampersand, ie &SCB->VTOR 

[hossein hosseini]

Posted on October 10, 2017 at 13:16

i know what happend in

headers

and i found the registers on

headers

.

But see  code please:

typedef struct

{

  __IO uint32_t CR;

  __IO uint32_t CFGR;

  __IO uint32_t CIR;

  __IO uint32_t APB2RSTR;

  __IO uint32_t APB1RSTR;

  __IO uint32_t AHBENR;

  __IO uint32_t APB2ENR;

  __IO uint32_t APB1ENR;

  __IO uint32_t BDCR;

  __IO uint32_t CSR;

} RCC_TypeDef;

and address of  RCC registers is 0x4002 1000 to 0x4002 13ff  so we know that first register CR allocate in 0x4002 1000 -

and we know this register get 32bit(4byte) get memory;

and now is it true that after 32 bit finished the first bit of CFGR register will start ? or  does CFGR address start from another address?

i mean  dose the registers start 

Continuous or no ??

and i'm thinking about that the RCC register start from 0x4002 1000 and finish 0x4002 13ff , if you Mines these address , we get 3ff , in decimal 3ff equale to 1023 , it means we have 1024 byte memory but we need just  (number of register * (32 / 8))byte memory for register , 12 * 4 = 48byte  just we need , why do we have 1024byte memory for this register ??does others memory is extra?

thanks alot.

[Tesla DeLorean]

Posted on October 10, 2017 at 14:10

&RCC->CFGR == 

0x40021004

The address decoder has a 1024 byte granularity into the peripherals(ie equivalent of a 'chip select' pin), the peripheral decode a subset of that.

[alexandre239955_stm1]

Posted on October 13, 2017 at 15:37

You need to read 3 documents:

- The specific Datasheet of the STM32 processor. Here you will understand the memory layout of the registers.

- The Reference Manual for the family of the processor. Then you will see bit by bit of each register, how they are grouped, etc.

- The Cortex-M Programming Manual for the processor. Here are the specific registers of the core processor, how the registers are stacked whe an interruption happens, the assembly instruction set, etc.

It's useful to compare these documents with the header files the processors. Most of the IDEs have one or more register description files for each supported processor (they are NOT the .h files, the format is different), and these files are used by plugins while debugging and you can inspect/change the registers freely. It helps a lot while learning how the API works internally.

Depending of what you are doing, you will need to read some application notes, because not all is explained on these 3 documents, like the initialization sequences for using a peripheral, how to program the flash memory, and other things. Most of the example codes are already respecting these initialization sequences, by the way.