Have a problem with write Scatter-Loading Description File for STM32H743.

[AOrlo.2]

Have a problem with write Scatter-Loading Description File for STM32H743 (arm keil).

I need to map SDRAM memory.

Regular I do it like:

RW_RAM1 0xD0000000 0x00800000 { ; fmc bank 2

  *(SDRAM)

 }

On all other MCU's it's work perfect, but not for stm32H7. 

It's fail on BX R0 command from startup file:

LDR   R0, =SystemInit

         BLX   R0

         LDR   R0, =__main

         BX   R0 //after this command

[FBL]

Hello @AOrlo.2​ 

Could you share a screenshot of your faults state using CubeProgrammer (in hot plug mode) or on Keil using Faults report?

You may refer to configuration 6 using scatter file remapping SDRAM.

X-CUBE-PERF-H7 - STM32H7 performance software expansion for STM32Cube (AN4891) - STMicroelectronics

Hope this help!

Firas

[AOrlo.2]

Hello,

Some video of debug from start to error (with registers and call stack):

https://youtu.be/G6puIUYvZVo

With Faults Report panel

https://youtu.be/63jFlBYZvQM

The SDRAM is still not initialized, but just for debuging, I don't call and don't use this memory in code. So on this state, compiler don't try to create any initialized(zeroed) memory in SDRAM.

I just want to create region.

[FBL]

Hi again @AOrlo.2​,

It appears that the linker has placed some variables in the SDRAM memory region starting at address 0xD0000000.

You can check the map file to find out what is located in this region.

[Tesla DeLorean]

Have a Hard Fault Handler that outputs actionable information.

Make sure the FPU is enabled.

Look at what gets moved or loaded in SDRAM

Makes sure the SDRAM is initialized in SystemInit() not later in main()​

[AOrlo.2]

From map file:

  Execution Region RW_RAM1 (Exec base: 0xd0000000, Load base: 0x0800e9c0, Size: 0x00000000, Max: 0x00800000, ABSOLUTE)

  **** No section assigned to this execution region ****

[FBL]

Hello @AOrlo.2​,

I guess there is a point missing here

uint16_t bufersdram[10] __attribute__ ((section(".SDRAM")));

[AOrlo.2]

Why?

If I use point like (".SDRAM"), so compiler don't see this section and put it to 0x24000000

If I don't use point ("SDRAM"), I see that it maped to 0xD0000000.

[FBL]

@AOrlo.2​  Are you using a customized Hardware setup or ST's Board? If possible, please attach binary file.

[AOrlo.2]

Use Waveshare CoreH7XXI

[AOrlo.2]

I have compleatly workable project on CoreF7XXI

But problem that CoreF7XXI no more in stock..

So I try to convers it to H7.

[VNA]

@AOrlo.2 Any solution you found? I am also facing similar issue.

[ukzw]

I met exactly the same problem. By step-in to __main assembly, found the reason is that, __scatterload is trying to copy variables from load address to exec address, which include copy to external SDRAM (0xd0000000), but at this time, external SDRAM not initialized yet, this caused hard fault.

Unfortunately with ARM compiler, unable to find a way to solve this. Looks need ARM support  

[mƎALLEm]

---

@ukzw wrote:

I met exactly the same problem. By step-in to __main assembly, found the reason is that, __scatterload is trying to copy variables from load address to exec address, which include copy to external SDRAM (0xd0000000), but at this time, external SDRAM not initialized yet, this caused hard fault. 

---

You need that SDRAM is initialized before calling the main() otherwise you will fall in Hardfault.

You can refer to the X-CUBE-H7-PERF

 and see how the scatter file under: Projects\STM32H743I_EVAL\stm32h7x3_cpu_perf\MDK-ARM\scatter_file\6-M7-ITCM_rwExtSDRAM.sct

and the SDRAM is configured in SystemInit_ExtMemCtl() in system_stm32h7xx.c are made: need to activate the definition of DATA_IN_ExtSDRAM

And becarefull if you are trying to execute from 0xD0000000, you will fall also in a fault as that region is Execute-Never as described by ARM. So you need to disable it with MPU.

 

[ukzw]

Thanks SofLit pointing me to X-CUBE-H7-PERF, problem solved!

However I have a few comments wish someday ST/ARM can consider.  

I only need store some user data into SDRAM, a simple flag such as "NOLOAD" - maybe GCC have this - shall be easily meet this requirement. I appreciate ARM has reasons to request SDRAM initialization before the main(), but this makes things complicated. system_stm32xx.c is a system file auto-generated, we write application code can expect just use it without need change inside, now I have to add my own code inside this file, which can make future software maintenance difficult.

Also the added code is to directly change the registers - a lot of "magic numbers" makes code difficult to understand. I use H757 with a 16bit width SDRAM, not the same as   X-CUBE-H7-PERF which use H743 with a 32bit  width SDRAM, so have to do some changes at the register level, this is not very nice code.

If use a flag such as "NOLOAD" to allow running to main() without go to hard fault, then we can initialize SDRAM by use HAL, the code can be much clean and easy to maintain.