Reputation: 43
I'm working on a bigger project in my Cortex M3 chip and I'm running low on the RAM. My proposed idea is, I need to make space in my RAM by removing the global variables on the bootloader code so that the RAM is cleared in the region after the bootloader jumps to the application code. I don't have direct access to the bootloader code in the chip, so I must change these global variables within the application code.
How can I remove this global variables with custom_delete()
function or any code . I use ARM cortex M3 (LPC1769).
To summarize, basically what I'm running is:
Custom_Delete ( ? ){
??
}
int foo[1000];
int main(){
/*
Bootloader Code
*/
Custom_Delete ( foo ) // I'm trying to remove the "foo" variable once the bootloader code is executed and the application code is run.
SCB->VTOR = (APP_START_ADDRESS) & 0x1FFFFF80 // jump to application code
}
Upvotes: 0
Views: 1184
Reputation: 659
You could force the linker to put a global variable into an self defined section:
__attribute__ ((__section__(".init.text"))) int my_global[128];
Then you have to edit your linker script so that this section can be reused later.
Linux does that too: What does __init mean in the Linux kernel code?
Upvotes: 1
Reputation: 31366
Arrays cannot be deleted, and since it is a global array, it is static and will exist until the program terminates.
The only solution I can see is something like this:
//int foo[1000];
int *foo;
int main(){
foo = malloc(sizeof *foo * 1000);
/*
Bootloader Code
*/
free(foo);
SCB->VTOR = (APP_START_ADDRESS) & 0x1FFFFF80 // jump to application code
}
You could possibly change the malloc
to alloca
and skip free
. But then you need to move the alloca
call inside the boot loader code. malloc
allocates on the heap and alloca
on the stack.
Another alternative is to simply rewrite the code so that the array simply is not global, but declared inside a function called by main()
.
Upvotes: 0
Reputation: 12404
Removing variables with static lifetime is not possible.
You might try to reuse the area.
union {
struct { // bootcode data
int foo[100];
};
struct { // application data
int var1;
long var2;
};
} data;
The names of the members should be unique between boot code and application. Then you can use unnamed members and access the fields without extra level of nesting. Data that is used both by boot code and application must be placed outside that union. This approach has the drawback that you cannot initialize data of the application that is in the union. Only first field of the union (i.e. the boot code part) can be initialized.
Note:
This applies if you have the bootcode and the application in the same executable.
If both are created in independently, then you can just use tailored linker scripts to place data in same location. As soon as you pass controll to the applicatin, the memory layout of the boot code is no longer relevant. This also allows initialization of application data if the startup code for the application is run when starting the application. That is normally true if you build the application as an independent binary.
Upvotes: 4