2020-02-13 01:49 AM
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
2020-02-13 01:53 AM
Did you enable the appropriate clocks?
2020-02-13 02:17 AM
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
2020-02-13 02:38 AM
Many Cortex M variants give you hardfaults when trying to access peripherals without enabling their clock first.
2020-02-13 02:53 AM
STM32 mostly returns 0 on reading a not properly clocked peripheral, but in some cases it can lock up completely.
2020-02-13 03:18 AM
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.
2020-02-13 03:24 AM
I tried to write to that address space with
uint32_t* ptr = 0x40004c00
*ptr = 0xFEEDFACE;
but with no effect. Memory View shows 0x00000000.
2020-02-13 03:26 AM
I meant --> uint32_t* ptr = (uint32_t*) 0x40004c00
2020-02-13 03:30 AM
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.
2020-02-13 03:54 AM
Enable the required clocks in RCC->AHB*ENR / ABP*ENR registers.