2020-03-06 11:33 AM
Still learning H7 so apologize for a silly question.
I want to use all Dx RAM parts on a single core STM32H743: D1, D2, D3.
Now, in system_stm32h7xx.c , SystemInit there's following code:
#if defined (DATA_IN_D2_SRAM)
/* in case of initialized data in D2 SRAM , enable the D2 SRAM clock */
RCC->AHB2ENR |= (RCC_AHB2ENR_D2SRAM1EN | RCC_AHB2ENR_D2SRAM2EN |
RCC_AHB2ENR_D2SRAM3EN);
#endif /* DATA_IN_D2_SRAM */
RM0433 says about RCC_AHB2ENR_D2SRAM1EN "When set, this bit indicates that SRAM1 is allocated bu the CPU", and same about SRAM2EN and SRAM3EN. But wait, SRAM1 (does it mean D1_SRAM aka AXI_SRAM?) already is accessible by the CPU? And, if I have initialized data in D2 SRAM, is it too late to enable it, because initialization of data is in the .s startup file, before SystemInit is called?
By testing it looks like D2 and D3 RAM can be read and written by the CPU even if RCC->AHB2ENR is 0.
The question is, do I need to uncomment these lines in SystemInit? Are they actually intended for multi-core H7 MCUs? Can anything bad happen if I leave RCC->AHB2ENR as 0?
Thanks in advance,
-- pa
Solved! Go to Solution.
2020-03-08 01:26 PM
Read my answer again carefully. D3 SRAM a.k.a. SRAM4 is always enabled. Yes, the naming is confusing.
D2 SRAM{1,2,3} should be enabled before first use. Find a place to do it before it is needed by anything. There is an assembler snippet in Clive1's links, to be put at the top of Reset_Handler, that should cover every possible use.
2020-03-06 12:21 PM
The thing is apt to Hard Fault, just add some code in the front-end of the Reset Handler,
https://community.st.com/s/global-search/d2sram
2020-03-06 11:58 PM
> SRAM1 (does it mean D1_SRAM aka AXI_SRAM?)
No.
RM0433 2.4 Embedded SRAM:
AXI SRAM = D1 SRAM at 0x24000000
AHB SRAM{1,2,3} = D2 SRAM{1,2,3} at 0x30000000
AHB SRAM4 = D3 SRAM at 0x38000000
8.5.9 General clock concept overview:
AXI SRAM, DTCM, ITCM, and SRAM4 are always enabled
AHB SRAM{1,2,3} can be selectively enabled in RCC.
> if I have initialized data in D2 SRAM, is it too late to enable it, because initialization of data is in the .s startup file, before SystemInit is called?
Yes. But startup*.s (the one used with gcc) can only initialize a single contiguous memory are, you should arrange the initialization of the rest yourself.
2020-03-07 12:48 AM
> By testing it looks like D2 and D3 RAM can be read and written by the CPU even if RCC->AHB2ENR is 0.
Yes, in the sense that you don't get a bus fault.
But data is lost when it's evicted from the L1 cache.
volatile int *sram = (volatile int *)0x30000000;
int main(void) {
volatile int i, j;
//RCC->AHB2ENR |= RCC_AHB2ENR_D2SRAM1EN | RCC_AHB2ENR_D2SRAM2EN | RCC_AHB2ENR_D2SRAM3EN;
SCB_EnableDCache();
SCB_InvalidateDCache();
__ISB();
for(i = 0; i < 0x12000; i+=1024) { // 0x12000 * sizeof(int) = 288k
for(j = 0; j < i; j+=4) {
sram[j] = j;
}
for(j = 0; j < i; j+=4) {
if(sram[j] != j)
while(1)
__NOP(); // fail, examine i
}
}
while(1)
__NOP(); // success
}
Data area in the linker script is set to DTCM. It fails at i>4096, i.e. it cannot hold more than 16 kilobytes.
2020-03-08 01:03 PM
@berendi If D2 SRAM needs to be enabled, it becomes more interesting.
I cannot afford stop using Cube yet. So...
In the default system_stm32h7xx.c initialization of RCC->AHB2ENR is commented out.
All the ethernet-related pools and buffers in ST examples sit in the top 32K of the D2 SRAM.
But I still can get ethernet doing something...
Will re-test with D2 uncommented.
And what with D3 DRAM? there's no similar snippet in system_stm32h7xx.c for D3 SRAM.
> But startup*.s (the one used with gcc) can only initialize a single contiguous memory are, you should arrange the initialization of the rest yourself.
Yes, sure. thanks.
-- pa
2020-03-08 01:26 PM
Read my answer again carefully. D3 SRAM a.k.a. SRAM4 is always enabled. Yes, the naming is confusing.
D2 SRAM{1,2,3} should be enabled before first use. Find a place to do it before it is needed by anything. There is an assembler snippet in Clive1's links, to be put at the top of Reset_Handler, that should cover every possible use.