STM32H74x/75x SDRAM (re-)mapping and caching

[regjoe]

Hello,

maybe this MCU is pretty old but... I'm designing HW for the H75x using SDRAM on bank 1 (SDCKE0+SDNE0).

RM0433 table 154 shows text "SDRAM bank 1" at 0x7000.0000 and 0xC000.0000, also figure 98 but table 7 "Reserved or remap of SDRAM Bank 2".

Q1: Is this an error in the documentation? If so, which table is correct?

Q2: Does this mean that SDRAM is accessible at two different memory regions at the same time, e.g. SDRAM bank 1 at 0x7000.0000 and 0xC000.0000? How, what for?

Q3: I guess that storage in the "External Devices" region (BTW: what does this name stand for?) is not write cacheable, not executeable but read cacheable?

Q4: If the NOR/SRAM bank is remapped to this region, the MCU cannot execute code from this device?

Q5: If the SDRAM is in the "External Memories" region, does this have a significant performance boost e.g. if data is stored here? Is there any drawback?

I have a STM32H753_EVAL2 on my side so I can do some tests if required/recommended.

Best regards

[SofLit]

Hello @regjoe,

---

@regjoe wrote:

Hello,

maybe this MCU is pretty old but...

---

We don't consider it as an old MCU ;)  and I invite you to read the AN4891 "STM32H72x, STM32H73x, and single-core STM32H74x/75x system architecture and performance"

I think most of question are answered there.

[regjoe]

Hello SofLit,

thanks for your fast reply.

I already noticed AN4891 but unfortunately, it did not answer all my questions.

Regarding Q1, it increases the likelyhood that there is an error in RM0433 table 7, but still unconfirmed.

Regarding Q3, I'm still puzzled about the meaning of "cacheable". Does it stand for "read / write cacheable"? I'm still unsure if "External Devices" is "read cacheable" or not.

Regarding Q5, AN4891 table 20, it is hard to believe that there is obviously no difference if SDRAM is in a "cacheable" region or not. If somebody has an explanation for this, please let me know. Otherwise I'll dive into the code and check it out on the EVAL board.

Regarding Q2/Q4, please point me to the appropriate information to answer these questions.

Best regards

[SofLit]

Hello,

---

@regjoe wrote:

I already noticed AN4891 but unfortunately, it did not answer all my questions.

---

This is why I've anticipated by mentioning "most of questions" not all of them.

Regarding your question "Q2: Does this mean that SDRAM is accessible at two different memory regions at the same time, e.g. SDRAM bank 1 at 0x7000.0000 and 0xC000.0000? How, what for?"

I think it's an address with an alias so it's accessible on both addresses: cacheable/executable - not-cacheable/execute never.

In default mapping SDRAM BANK1 is seen in both addresses: 0x7000 0000 & 0xC000 0000.

Same case for SDRAM BANK2 BMAP[1:0] = 01b: SDRAM BANK2 is seen in both addresses: 0x7000 0000 & 0xC000 0000. I need to confirm that internally and get back to you.

The cachability is something seen by the Core itself and depends on the default MPU config.

For ARM this is the default memeory attributes for CM7:

AN4891 / Table 3:

Type: Normal means cacheable, Device means not cacheable.

Even you enable the cache and you perform an access to a Device region it will be not cacheable.

regarding your question Q5: 

These results are provided for STM32H743-EVAL board and the default SDRAM BANK2 address (without swap) is 0xD000 0000 which is not cacheable and Execute NEVER..

So to make that region cacheable/executable, either to swap the address using BMAP[1:0] bits or configure that 0x7000 0000 (see table 3 above) or configure that region (0xD000 0000) as cacheable and make it executable. Please refer to the package X-CUBE-PERF-H7  / Config 6 - D1_ITCM - D1_SDRAM / Project config: SDRAM_ADDRESS_SWAPPED.

This is how it was implemented in system_stm32h7xx.c:

#if defined (SDRAM_ADDRESS_SWAPPED)	
	 /* Since the default SDRAM address region (Bank 2) is not cacheable (0xD0000000),
  	  remap it on address 0x70000000 which is cachable. */
	 FMC_Bank1->BTCR[0] &= 0xFCFFFFFF;
	 /* NOR/PSRAM bank and SDRAM bank 1/bank2 are swapped. */
	 FMC_Bank1->BTCR[0] |= ((uint32_t)(1 <<24));
	
#else	/* ! SDRAM_ADDRESS_SWAPPED */
	
/*** MPU configuration ********************************************/	
  /* Configure MPU to allow the code to execute from SDRAM */	
	/* Disable MPU before configuring it */
  MPU->CTRL &= ~MPU_CTRL_ENABLE_Msk;
	/* Configure SDARM region as first region */
	MPU->RNR  = MPU_SDRAM_EXEC_REGION_NUMBER; 
	/* Set MPU SDARM base address (0xD0000000) */
  MPU->RBAR = MPU_SDARM_BASE_ADDRESS;
  /*
	    - Execute region: RASR[size] = 22  -> 2^(22+1) -> size 8MB
	    - Access permission:  Full access: RASR[AP] = 0b011
	    - Cached memory:  RASR[TEX] = 0b0100
	    - Disable the Execute Never option: to allow the code execution on SDRAM: RASR[XN] = 0
			- Enable the region MPU: RASR[EN] = 1
	 */  	
  MPU->RASR = (MPU_SDRAM_EXEC_REGION_SIZE | MPU_SDRAM_ACCESS_PERMSSION | MPU_SDRAM_REGION_TEX | \
	             MPU_RASR_ENABLE_Msk | MPU_SDRAM_REGION_BUFFERABLE) & ~MPU_RASR_XN_Msk  ;
  
  /* Enable MPU and leave the predefined regions to default configuration */
  MPU->CTRL |= MPU_CTRL_PRIVDEFENA_Msk |  MPU_CTRL_ENABLE_Msk;	
	
#endif	 /* SDRAM_ADDRESS_SWAPPED */  

So, the two performance have almost the same result if:

The data are located in NORMAL region with cache enabled either by swapping the address or by configuring it as Normal using MPU.

[regjoe]

Hello SofLit,

I got it running but first of all I had a build problem in CubeIDE. The error message is

arm-none-eabi-gcc: warning: INITIAL_SP_BASE_ADDRESS=0x24000000: linker input file unused because linking not done

I replaced

-defsym INITIAL_SP_BASE_ADDRESS=0x24000000

using a #define in main.h. The output is

Config.: 10 - M7 - Exec in ExtSDRAM - Data in DTCM
(const in SDRAM)
IDE: ARM GCC
CM7 frequency: 400MHz (tcpu = 2.5 ns)
AXI and AHBx frequency: 200MHz
| Flash WS | D-cache | I-cache |
| NA | ON | ON |
FMC SDRAM config:
| Mem CLK freq | Mem Bus width |
| 100.0 MHz | 32 |
maxValue = 327.572052 , status = 0
- Systick interrupt cycles = 88
- Total number of cycles = 124348
- Execution time = 310870.0 ns

I tried to Debug the application, but it stops with

Error: Failed to set breakpoint at address: 0x70000000.

Seems to me that the onboard debugger cannot set a breakpoint in this memory region?

Nevertheless, this shows that the remapping 0xD000.0000 -> 0x7000.0000 was successful.

Next I undefined SDRAM_ADDRESS_SWAPPED and got the almost same execution time (310835.0 ns). 

And again, debugging is not possible, same error and address.

There is no breakpoint set or active, I deleted all breakpoints to make sure.

I would have expected that I can debug some lines of code in internal memory until there is a jump e.g. to external memory. But this error appears immediately. Does this imply that the compile flag doesn't work as expected? Any clue?

Regarding the code snippet above: I understand that if the compile flag is set, remapping 0xD000.000 to 0x7000.0000 is done. The 0x7000.0000 region is cacheable and executeable.

But, if the compile flag is not set, no remapping is done. Now the 0xD000.0000 region is configured to cacheable and executeable. Am I right?

The linker always produces code for 0x7000.0000, so the magic is in the following line

 MPU->RBAR = MPU_SDARM_BASE_ADDRESS;

which sets the register to 0xD000.0000

What puzzles me most: 0xD000.0000 is in the Device region. According to table 3, this region is by default not cacheable and not executable. So this region can be set to executeable but not set to cacheable. Is this correct?

Here are my results

Test	DCACHE	ICACHE	ADDRESS_SWAP	Result [ns]
1	ON	ON	ON	309570
2	ON	ON	OFF	309420
3	ON	OFF	ON	1912052
4	ON	OFF	OFF	1911332

5	OFF	ON	ON	581450
6	OFF	ON	OFF	580778
7	OFF	OFF	ON	2378017
8	OFF	OFF	OFF	2377728

In my test here there is almost no difference if remap is done or not. So what is it good for? Is there something wrong with the benchmark demo? Using #error I verify that the appropriate code section is compiled.

[SofLit]

Note that the examples provided was provided for KEIL, IAR and System Workbench at that time (the release of the application note) CubeIDE wasn't available and the results was provided for KEIL ONLY as mentioned in the application note. IAR and System Workbench have also almost the same results.

Sorry I cannot help you for CubeIDE. You may download the System Workbench IDE for STM32 on this link and retry the tests: https://www.st.com/en/development-tools/sw4stm32.html

[regjoe]

In this case I'll give KEIL a try and get back here.

[SofLit · Accepted solution]

Hello @regjoe ,

Getting back to your original question regarding the SDRAM mapping, the reference manual and the application note are correct and confirm my saying: the SDRAM has an alias and seen by CPU on both addresses on the same time.

[regjoe]

Hello SofLit,

if Table 7 is correct, it is confusing me. "Reserved" does not necessarily imply an "alias" feature, IMHO.

Thanks

[SofLit]

Hello, 

I see .. Will be escalated internally..

reserved needs to be "SDRAM BANK1 or remap SDRAM2"