cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F746BG Offload .rodata onto QSPI

JHarding
Senior

Hello,

I have moved an .rodata portion of a file onto the QPSI. This happens to be a TouchGFX file that has a lot of rodata. It is FrontendApplicationBase.o

When I change code else where in my project (unrelated to TGFX or the FrontendApplicationBase), the contents of my QSPI change, why is this?

My on board Flash is near full and I would like to offload some rarely changed files without having to flash the QSPI memory with every change I make to any file. I can provide more information if needed.

8 REPLIES 8

Read Only means it doesn't change after it is written to memory,not that the build/link process will get the same output every time.

If the data contains class related function calls, and call backs, these might change every time it is built.

Relative calls to functions in other code regions might also expand/contract, but generally will need longer forms.

You'd need to do a deeper dive into the actual nature of the data and the changes.

You might want to subdivide the QSPI into sections, and micro-manage the placement of functions and libraries in different memory areas, and perhaps automate the process of scanning the map or object files and generating a consistent working set between build.

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

Thanks @Community member​. Do you have any reference material on how to maintain the same output from one build/link cycle to the next. I've been full steam ahead searching, but I think my lack of knowledge in this area is limiting the results I can find because I don't know what to actually search for.

I have been using the GNU ld reference as my bible for the past week, and it has gotten me a broader sense of the linking process, but I still feel far away from the knowledge I need to accomplish my goal.

For example, the object file for FrontendApplicationBase is the exact same from one build to the next, but the linker process is doing something to change the order/structure of the bin file that is produced.

Pavel A.
Evangelist III

Have you tried to compare .map files? compare .bin files?

I have been looking at the produced map files, but I haven't compared them, I will start doing that to see some differences. I have been using AMap to analyze the MAP file.

I have been diffing the bin files, but my experience there is lacking. I can see certain portions of the firmware move around as I modify the linker script, and I can see bytes change here and there. I haven't really developed a method to my madness just yet. Do you have any good ideas @Pavel A.​ ?

What modification of linker script do you mean?

If I understand correctly you've moved some section to the address range of QSPI.

After doing this once, you want to "freeze" the content of that section. So the linker script should not change after the freeze.

Now you state that after some change that does not touch the "frozen" area, its content still changes ?

@Pavel A.​ That is correct. The below is a section of my linker script that works wonderfully. The BitmapDatabase.o file and its contents in my bin don't change unless I add a bitmap, or in other words doesn't change unless something in that file or related files changes. As @Community member​ has mentioned, I do believe this has to do with what the files contain. For example, the BitmapDatabase is mostly const uint16_t, so when I modify code elsewhere it doesn't really effect the const data in BitmapDatabase.o. Whereas, the FrontendApplicationBase.o file contains functions, variables, typedefs, etc.

.QSPICODE :
  {
    . = ALIGN(0x4);
    *(.QSPICODE .QSPICODE*)
    *(.gnu.linkonce.r.*)
    *BitmapDatabase.o (.rodata .rodata*)/*Includes the files mentioned fromt the specified sections */
    . = ALIGN(0x4);
  } >QUADSPI

My Impression what that if I did something like this:

.QSPICODE :
  {
    . = ALIGN(0x4);
    *(.QSPICODE .QSPICODE*)
    *(.gnu.linkonce.r.*)
    *FrontendApplicationBase.o (.rodata .rodata*)/*Includes the files mentioned fromt the specified sections */
    . = ALIGN(0x4);
  } >QUADSPI

that only the rodata would get stored in that portion of the QSPI, which I think is true. The problem is that as @Community member​ mentioned:

Relative calls to functions in other code regions might also expand/contract

and I think this is pushing data around in ways that I don't fully understand.

Yes if there's code there and it changes, this can explain it. Can you do better separation of data (resources) from code in QSPI? Like, define a separate section for the code?

That's the thing, the code within FrontendApplicationBase.o doesn't change, its code elsewhere that changes and seems to be imparting change on the final binary that I am pushing to QSPI. I have tried creating a separate section for .text and .text* but the same issues arises.