We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I am writing an application where my code is split into two sections. One section contains the boot loader (internal micro memory sec[1]) which loads the functional part of the code into ext flash -sect[2]. After the functional code is loaded and it is running in the flash it returns to the internal code to process interrupts and perform flash writing utilities. I have no trouble placing the code subroutines into the proper place in memory (ie either internal or external address ranges) using the linker SE command. But I am trying to guarentee that when functions are called from the functional(flash) code to the micro side that all data is passed on the stack(or in registers) as apposed to fixed addresses. This is because my micro code is not intended to change even when my functional code is upgraded and rebuilt. I tried using the NO OVERLAY command to the linker but one of my function parameters is still assigned an XDATA address as well as my function returns. At the very least I would like them to be stored within the internal micro RAM (preferably if not stored on the stack). My intention is not to disturd the code on the micro side once it is initially created. If I try compiling my internal code with a different memory model my linker complains about incompatible memory models.
The linker shows a name called _XDATA_GROUP_ can I locate this to an absolute memory address within XDATA, using the linker????????????
Just get rid the nonregistered paramters by just passing a single pointer to a parameter block.
typedef struct { int Parm0; int Parm1; int Parm2; int Parm3; int Ret; } ParmsT; void FnA( ParmsT* pParms ) { pParms->Ret = pParms->Parm0 + pParms->Parm1 + pParms->Parm2 + pParms->Parm3; } main(void) { ParmsT data Parms; Parms.Parm1 = 1; //.. and so on FnA( &Parms ); //Parms.Ret is now valid }
Thanks Jon, I am still curious if anyone knows how to directly locate the data group that the linker produces. I thought of maybe reserving memory... and this might force it to be located somewhere else. I would think there would be another way. I could unreserve it if additional memory is needed by the application. Can anyone answer this?
In the BL51 linker you use the option:
XDATA(_XDATA_GROUP_(0X100))
Thanks Jon