2021-08-13 11:56 PM
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 ?
Solved! Go to Solution.
2021-08-14 05:34 AM
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
2021-08-14 12:45 AM
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.
2021-08-14 03:20 AM
@Community member Perfect..
I need some more clarifications.
2021-08-14 05:34 AM
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
2021-08-14 06:01 AM
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 ?
2021-08-17 11:20 PM
@Community member Could you please update on this ?
2021-08-18 03:57 AM
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.
2021-08-18 04:49 AM
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.