AnsweredAssumed Answered

EGUI port to Crossworks: can't get relevant const sections in RAM

Question asked by Robert Wood on May 19, 2013
Latest reply on Jul 10, 2013 by Petr Gargulak

We're porting a few Kinetis applications from Codewarrior to Rowley Crossworks (I should stress they are both gcc based IDEs). The compiling wasn't too difficult, but the processor is crashing because it's trying to write some data into an object into, but the area it's trying to write to is in flash. In Codewarrior, the object has the same area in RAM, not flash.


I've dug into the layer upon later of macro definitions to get a half-decent understanding of how these EGUI objects work and I can't see that I'm doing anything wrong in the C code (after all it does compile), so I am wondering whether it's a linker issue.


The issue boils down to these objects (I have expanded macros and missed some stuff out for clarity):


static const D4D_LABEL scrSplash_lblSID_params

= { { "   Unit ID: 42949672955" , sizeof("   Unit ID: 42949672955"), 0, &scrSplash_lblSID_strPrties}, { 6, 76 }, { 118, 16 }, 8 };


const D4D_OBJECT scrSplash_lblSID = { (void*)&(scrSplash_lblSID_params), (D4D_OBJECT_SYS_FUNCTION*)&d4d_labelSysFunc,

(void*)0, (void*)0, (0x01 | 0x02 | 0x40), &(scrSplash_lblSID_flags), (void*)0, &(scrSplash_lblSID_pScreen) };


The thing to really focus on is the scrSplash_lblSID_params


When the function below is called with the object passed being scrSplash_lblSID:


void D4D_SetText(D4D_OBJECT_PTR pObject, char* pText)




  D4D_STRING* p_TextBuff = NULL;






    p_TextBuff = pObject->pObjFunc->GetTextBuffer((D4D_OBJECT*)pObject); 


// ABOVE line equates to: return &(((D4D_LABEL*)((pThis)->pParam))->textBuff); 






    D4D_ChangeText(p_TextBuff, pText, 0); 


    D4D_InvalidateObject(pObject, D4D_FALSE);






Then the p_TextBuff is returned by this line:


p_TextBuff = pObject->pObjFunc->GetTextBuffer((D4D_OBJECT*)pObject); 


...which is a pointer to a D4D_LABEL, and is definied as follows:


typedef struct




    D4D_STRING textBuff;    // label text


    D4D_POINT scrPos;        // position on the screen


    D4D_SIZE  scrSize;       // size on the screen (focus rect only, bitmaps have own size)   


    D4D_COOR radius;         // corner radius




D4D_STRING is defined as:


typedef struct D4D_STRING_S




  char *pText;


  D4D_INDEX buffSize;


  D4D_FONT fontId;


  D4D_STR_PROPERTIES *str_properties;


  D4D_INDEX printLen;


  D4D_INDEX printOff;




This is the area it falls over under Crossworks. With Codewarrior, the pointer, pText points to an area of RAM. With Crossworks, it points to flash and so when D4D_ChangeText() is called, it is passed a pointer to an area of flash, the processor attempts to write the new string into that area of flash and the processor crashes.



Remember that scrSplash_lblSID_params is defined as this:


static const D4D_LABEL scrSplash_lblSID_params


= { { "   Unit ID: 42949672955" , sizeof("   Unit ID: 42949672955"), 0, &scrSplash_lblSID_strPrties}, { 6, 76 }, { 118, 16 }, 8 };


And it's this area of memory:


"   Unit ID: 42949672955"


That should be pointing to RAM. It is pointing to RAM in the Codewarrior version, but I don't quite see how, because it is defined as a static const (in both IDEs) which puts it in flash.


Is anyone able to advise on how this can be? How can a static const, in this case, be pointing to RAM and not flash? IS this something that can be done in linker file? I don't see how as other static const declarations are (quite rightly) in flash!


Many thanks.