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

[DiBosco]

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;

  if(pObject->pObjFunc->GetTextBuffer)

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

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

  if(p_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_LABEL;

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;

}D4D_STRING;

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.

[Gargy]

Hello,

is strange that the CW GCC is placing this string to the RAM. Normally is this string natively placed in ROM area (flash), that's original behaviour of eGUI.

For example standard text declaration in object (non changeable):

D4D_DECLARE_STD_LABEL(lbl_test, "My text", 10, 10, 100, 20, FONT_SYSTEM)

For example standard text declaration in object ( changeable):

D4D_TCHAR lbl_test = "My Text";

D4D_DECLARE_STD_LABEL(lbl_test, lbl_test_str, 10, 10, 100, 20, FONT_SYSTEM)

Petr

[DiBosco · Accepted solution]

Hi Petr and thanks for the reply.  :smileyhappy:

I did post a query on Stack Overflow in the end and there was much debate out this. Finally, I solved it with the advice that is should be done this way:

char mystring[] = "This is my string";

D4D_DECLARE_STD_LABEL(lbl_test, mystring, 10, 10, 100, 20, FONT_SYSTEM)

This then ensures that the string is stored in RAM. This issue, is that (apparently) the C standard does not specifically state where the original code should put the string. A friend who writes compilers tells me it is "undefined". Therefore the bloke who wrote the original software that I ported to Crossworks was unlucky that Codewarrior decided to put it in RAM whereas Crossworks thinks it should go in flash. (Maybe it was me that was unlucky!)  The fact it boils down to a const char would suggest to me, Crossworks is more logical. As both use the gcc, I can only assume Freescale have used a different version or doctored it slightly.

As soon as I sorted this, the Code pretty much worked straight off and it was really quite easy to get the whole system going on Crossworks instead of Codewarrior.

D4D_TCHAR is not defined in my version of EGUI, but I can't see the point of using it rather than just char as I assume that's what it is. It's like the #define D4D_CONST const - all that does it make the code hard to read.

[Gargy]

Hello,

good to hear that eGUI works correctly under CrossWorks.

D4D_TCHAR is new type defined in version eGUI 3.00 and it's added to help eGUI support standard ASCII and optionally UNICODE that needs at lest 16 bit variables.
Also the macros D4D_CONST and non CONST is just way how to simply create one declaration macro that allows create object as in RAM as FLASH (NVM) part of memory.

By the way the snapshot of eGUI 3.0 you can find in this thread: Re: Sample code request eGui + TWR-K70 + TWR-LCD-RGB + MQX + CW.

Petr