cancel
Showing results for 
Search instead for 
Did you mean: 

Sharing common flash memory space between two projects?

mani s
Associate III

0690X00000895fsQAA.pngI trying to make common address space for BT-stack in flash memory, show in below figure. I have two projects using same flash memory. In both the projects Bt stack is used, so, I thought to make common memory for BT stack so that both the projects can call functions and can reduce the flash memory size also.

Let's call OTA is project-1  and Application is project-2.Using Stm32f412CE controller with 512kbytes flash memory. BT stack will be in OTA project and storing in specific address location in flash memory. I need to call same functions which is stored in common place from application code as well.                                

                                                     

     

                                                     

I'm aware that I can use section attributes on functions and variables and then locate those sections at specific addresses during linking.

MEMORY

{

FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 128K

RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 16K

MEMORY_B1 (rx) : ORIGIN = 0x60000000, LENGTH = 0K

}

.ip_code :

{

*(.IP_Code*);

} > IP_CODE

__attribute__((section(".IP_Code"))) int placed_logic().

  1. How to arrange this memory layout when linking, and then further, how to expose BT library functions to the application code area?
  2. How to link the .elf file of ota code to application code?

12 REPLIES 12
turboscrew
Senior III

I think there is not enough information.

First, I couldn't figure out what you are trying to achieve.

Only one of the projects is running at a time?

Do you use some OS?

Do you need to be able to flash both projects as one?

Also, two projects mean two sets of resource allocations and compilation settings - there may be conflicts.

Why do you need two projects?

Depending on the situation, I might use an array of function pointers in the common area and link that array to an absolute address in both projects (something like device descriptors often are). In that case I'd use two separate images with a common linker script.

mani s
Associate III

Only one of the projects is running at a time ?

Only one project will be running at a time, I can choose either one of the project-1 or project-2 to be run.

Do you use some OS?

Yes, I'm using FreeRTOS OS. 

Why do you need two projects ?

Basically those are two different projects sitting in single micro-controller. I can choose any one of the them based on condition like power button and user button it will go to project-1, with normal power button it will go to project-2.

It is a huge BT stack libraries, so, I can't use function pointers for many functions. If you keep BT stack common, so that I can call functions from project-2 also.

And I can use less flash memory also by doing this exercise.

Did you get the clarity about the question?

Real problem calling code within another app is that it's view of RAM and where it's variables are will be completely different.

If I were building a common library, I'd probably make it a standalone image, with it's own RAM allocation not tied to anything else, and then exclude that RAM from the linker's view in the other apps, and provide entry points to the API via a definition file to the linker.

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

I didn't understand what you are trying to convey.

Is what I suggested making sense? or can we do it any other approach?

S.Ma
Principal

As there is no dynamic linking, it's not going to be easy to implement.

True, you can define say 3 flash sectors in the linker file to control where the flash functions and constant will drop. But the absolute address to call a program 1 function from common will change when it becomes program 2. The absolute address of constant data will too change.

Not exhaustive I would think of:

  • Copy program 1 or program 2 in RAM (and I suppose this has "cost" here vs complexity of the SW dev time
  • Use the ancien SWI (software interrupt BIOS method) where the functions which can be called from outside a region (and constant) have their location in a pointer array table which uses an absolute immediate index value. (make it indirect). This is extra dev effort and many checks will be needed.

Making sense?

S.Ma
Principal

Note: You will also have to make sure that the stack size is still good enough for both configurations.

The RAM heap global variables should also be placed by the linker at the same location (to check on the MAP file for example).

Also consider the proper handling of the interrupt vector table.

mani s
Associate III

thank you so much,

  1. you mean to say should use function pointers or something like that?

did i understood properly?

mani s
Associate III

yes, stack size for both the projects are good enough to place in flash memory.

Still in confusion how to approach this problem or solve this step by step?

can you me actually what need to do or read ?