cancel
Showing results for 
Search instead for 
Did you mean: 

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

AOrlo.2
Associate II

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

19 REPLIES 19
FBL
ST Employee

Hello @AOrlo.2​,

I guess there is a point missing here

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

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

AOrlo.2
Associate II

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
ST Employee

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

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

AOrlo.2
Associate II

Use Waveshare CoreH7XXI

AOrlo.2
Associate II

I have compleatly workable project on CoreF7XXI

But problem that CoreF7XXI no more in stock..

So I try to convers it to H7.

VNA
Associate

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

ukzw
Associate

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  


@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.

SofLit_0-1729266469191.png

 

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

>> Looks need ARM support  

As I said originally in the thread, the SDRAM needs to be initialized in SystemInit(), this is ** ARM'S ** expectation, it is the contract with you, so that the scatter loader can unpack into viable memory.

Initialize the clocks, pins and peripherals in SystemInit(), doing it in main() is far to late.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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.