cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H7 Device Running Code from RAM instead of NOR / Internal Memory

YSN
Senior

I have implemented my entire application in Touchgfx and FREERTOS and using the NOR flash as the external memory device.

Now, is there any way to copy the entire code stored in NOR to SDRAM and run execute from there. Just like boot loading from NOR to SDRAM for faster execution. Becuase I see some image flicker/slide effect with NOR flash and wanted to execute code from SDRAM.

Is it really possible with this device ?

1 ACCEPTED SOLUTION

Accepted Solutions

Ok, might make more sense using a method closer to the last one

You would need code called by SystemInit() to bring up QSPI and SDRAM, the scatter loader can then move things into their final locations.

The scatter file describes your two primary load regions, FLASH and QSPI

Within the FLASH one, describe Half the SDRAM (Bottom)

Within the QSPI one, describe the Second half of SDRAM (Top), and within that describe an executable section

Programming would then just need the Internal and External QSPI loader algorithms

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

View solution in original post

7 REPLIES 7

Sure

On the build side you want to tell the linker to use the 0xC0000000 SDRAM memory space instead of the 0x90000000 QSPI one, and partition and divide the SDRAM as desired. Use the linker script/scatter file to do this, perhaps split the SDRAM into two halves, with the lower half acting as buffering/ram as before, and the upper half to hold code image.

On the delivery side you need to write your binary executable blob into the QSPI memory, either as a direct one-to-one image, or as some sort of file system the loader can retrieve/index, and infer things like size, final location, etc.

On the loader side, bring up the clocks, and memory interfaces, both SDRAM and QSPI, the later you can memory map or use direct access command methods. Perhaps also have the loader set up MPU rules, etc. Finally the loader walks the data in the QSPI and memcpy()'s or processes the file system data ti=o move the executable image into SDRAM, and then finally transfers control into that image.

There are ways to do this with a single build, using the startup.s file, and load regions, directing the packing into FLASH/QSPI and subsequent unpacking into SRAM/SDRAM, with the compiler directing code/data into appropriate sections, but this is perhaps more convoluted than the more flexible download and run approach discussed first.

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

@Community member​ Perfect..

I need some more clarifications.

  1. As we are using STM32H745 MCU, it has 1MB of internal Flash, So the division of the code will be like all the external sections like fonts, texts, and images will be routed to external SPI flash by specifying under scatter file. Now we need to replace the QSPI (0x90000000 ) address with SDRAM so that it will create the symbol table with SDRAM addresses. During run time we can copy these sections from SPI to SDRAM and transfer the control so that it will execute from there. Pls confirm my understanding is right ?
  2. If so, then how to initially store the External Sections in QSPI flash with same format or replica of SDRAM addresses ? We can not anyway overlap SDRAM and QSPI sections in Scatter file right ?
  3. The delivery side blob includes these external executable image or only file boundary and size information.
  4. Can we achieve above with same .FLM file used for External SPI loader or need to make any changes ?

Ok, might make more sense using a method closer to the last one

You would need code called by SystemInit() to bring up QSPI and SDRAM, the scatter loader can then move things into their final locations.

The scatter file describes your two primary load regions, FLASH and QSPI

Within the FLASH one, describe Half the SDRAM (Bottom)

Within the QSPI one, describe the Second half of SDRAM (Top), and within that describe an executable section

Programming would then just need the Internal and External QSPI loader algorithms

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

Well, Now you mean by declaring SDRAM within QSPI, will actually generate address map corresponding(equivalent) to SDRAM memory locations ?

Can you please explain in more detail about linker settings in terms of address locations. We have QSPI at (0x90000000) and SDRAM at (0xD00000000). The Virtual LCD buffer is occupied till lets us say 1 MB.

The SDRAM is free from 0xD0100000 address space. But now How to specify same location for QSPI and SDRAM ? So that after copy still the symbol memory map is valid ?

@Community member​ Could you please update on this ?

No

This is the point where you spend some time reading the docs on scatter files​ and modify the model you have to the model you want. I don't have the resources to spend significant time on this.

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

No Problem, do you any application note or docs related to this problem.. I will read and implement..

BTW, I was only expecting the clarification on

Within the FLASH one, describe Half the SDRAM (Bottom)

Within the QSPI one, describe the Second half of SDRAM (Top)

Any how thanks for your support.