cancel
Showing results for 
Search instead for 
Did you mean: 

Cannot access memory of peripherals

MBos.1
Associate II

Hello everyone,

I am working with STM32H755ZI,, ARM GCC and J-Link GDB.

Considering Reference Manual the H755ZI has following Memory Map (cutout):

...

0x40007C00 - 0x40007FFF UART8

0x40007800 - 0x40007BFF UART7

0x40007400 - 0x400077FF DAC1

0x40006C00 - 0x40006FFF HDMI-CEC

0x40005C00 - 0x40005FFF I2C3

0x40005800 - 0x40005BFF I2C2

0x40005400 - 0x400057FF I2C1

0x40005000 - 0x400053FF UART5

0x40004C00 - 0x40004FFF UART4

0x40004800 - 0x40004BFF USART3

0x40004400 - 0x400047FF USART2

0x40004000 - 0x400043FF SPDIFRX

...

When I wanted to initialise the peripheral UART4 I noticed it's not possible to write to that memory space.

I tried with HAL Driver and then with direct register write but the memory does not change. I also tried the UART5, the I2C1, I2C2 and I2C3 without success.

Since these peripherals are all at the same memory part I thought about some kind of memory protection.

On the internet I found information about the Flash Patch and Breakpoints FPB and lock access register LAR. But writing 0xC5ACCE55 to memory 0xFB0 (LAR) like they propose didn't help.

On the same STM32H755ZI I had already got the USART1, USART3 (which is right below UART4 in memory space), USART6, the I2C4 and other peripherals working with the HAL Library.

Thanks for any help.

Kind regards

Michael

11 REPLIES 11
Uwe Bonnes
Principal II

Did you enable the appropriate clocks?

It's not a *memory*, it's an *address space*.

The peripherals have a handful of registers at the beginning at that space - see RM, register description for individual peripherals - but the vast majority of that space is simply unoccupied.

JW

Ozone
Lead

Many Cortex M variants give you hardfaults when trying to access peripherals without enabling their clock first.

STM32 mostly returns 0 on reading a not properly clocked peripheral, but in some cases it can lock up completely.

MBos.1
Associate II

Thanks for your answers.

@Uwe Bonnes​ Yes the clock is enabled. I use the clock settings CubeMX prepared for me. If the clocksource is missing, the HAL UART_Init would return HAL_ERROR, but it doesn't. It returns HAL_OK.

And I use the same driver for usart 1 and usart 1 is working. I can see the written registers in USART1,

Same issue with I2C. My driver works fine for I2C4 (different "address space", thanks @Community member​ ). But the same driver has no impact on the rgisters for I2C1 / I2C2 / I2C3.

I also tried on other H755ZI devices, same behaviour.

MBos.1
Associate II

I tried to write to that address space with

uint32_t* ptr = 0x40004c00

*ptr = 0xFEEDFACE;

but with no effect. Memory View shows 0x00000000.

MBos.1
Associate II

I meant --> uint32_t* ptr = (uint32_t*) 0x40004c00

As said before, peripheral registers are not memory, they are only mapped into memory space.

Only "some" addresses of the occupied space of each peripheral are taken by registers. Usually, they are size-aligned.

The reaction to access is arbitrary, depending on the peripheral. Some registers are only for write access.

Read the reference manual.

berendi
Principal

Enable the required clocks in RCC->AHB*ENR / ABP*ENR registers.