emWin text not being set correctly

[elliotrevell-na]

Hi

I have been working with emWin and a lpc4088.

I am having a problem with text in widgets not being set correctly.

This seems to be possible on every widget type that I have tried so far.

It can happen with _CreateIndirect and _SetText functions.

What happens is that the text sometimes gets set with extra characters or with characters missing.

Here is an example of a window with several different widgets all showing this problem.

Problems:

listbox should have several strings in it

button 1 should not have this extra 8

button 2 should not have 1/4

button testing should not have st on the end

listview should have an entry in each cell "pos(x,y)" (where x and y are column and row)

listwheel should have days of the week but Thursday has an extra character

I have attached this example as a zip.

Extra information:

I have reproduced this problem with gcc builds of emWin530 (with and without hardfloat) and emWin538.

I have tried stepping over TEXT_SetText() then TEXT_GetText() and seen that what I get back is not what I tried to set.

I have reproduced this with a single widget in the window. 

Seems more common to get extra characters than to have missing characters.

Any help would be greatly appreciated.

Thanks

Elliot

[soledad]

(On behalf of Carlos)

Hi,

In the last example, the memory content is still corrupted: 

the ascii sequence for "Item" has inserted a 00 : "54 00 74 65 6d".

Also, in the GUI_RAM.txt, the "pos(" strings all gets trailing char :

   70 6f 73 28 30 2c 30 29 94 00 -> pos(0,0)”

   70 6f 73 28 30 2c 31 29 4a 00 -> pos(0,1)J

   70 6f 73 28 30 2c 32 29 54 00 -> pos(0,2)T

   ...

The "94", "4a", "54" should not be there.

Could customer do some SDRAM access test?

Could also manually change the SDRAM content to see how the display is affected.

Regards

[Carlos_Mendoza]

Hi Elliot,

Could you please try increasing the amount of memory which is assigned to emWin? This might be the reason for this behavior.

Hope it helps!

Best Regards,
Carlos Mendoza
Technical Support Engineer

[elliotrevell-na]

Hi Carlos

Thanks for getting back to me.

Do you mean this section?

#define GUI_NUMBYTES 0x31F000

void GUI_X_Config(void) {
 //
 // 32 bit aligned memory area
 //
#ifdef __ICCARM__
#pragma location="GUI_RAM"
 static __no_init U32 _aMemory[GUI_NUMBYTES / 4];
#endif
#ifdef __CC_ARM
 U32 static _aMemory[GUI_NUMBYTES / 4] __attribute__((section("GUI_RAM"), zero_init));
#endif
#ifdef __GNUC__
 U32 static _aMemory[GUI_NUMBYTES / 4] __attribute__((section(".GUI_RAM"))) = { 0 };
#endif
 //
 // Assign memory to emWin
 //
 memset((uint8_t*)(&_aMemory[0]), 0x00, GUI_NUMBYTES);
 GUI_ALLOC_AssignMemory(_aMemory, GUI_NUMBYTES);
 //
 // Set default font
 //
 GUI_SetDefaultFont(GUI_FONT_6X8);
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

This seems like a huge amount of memory allocated and the problem persists.

Is there something I have missed here?

If I look at the contents of my memory in this .GUI_RAM section when this example is running I can see that only the first ~0x2700 bytes have been touched.

I can see the text displayed on the widgets in the memory too (I have attached a copy of the first region of my GUI_RAM section).

Regards

Elliot

[Carlos_Mendoza]

Hi Elliot,

Thanks for your response and information.

Yes, that is the section, it seems to be correct.

From the dumped file, it seems those strings are not null-terminated, not compliant with C's string. If GUI API allows you to assign the length of string that is not null-terminated, make sure the length parameter is correct.

Hope it helps!

Best Regards,
Carlos Mendoza
Technical Support Engineer

[elliotrevell-na]

Hi Carlos

Carlos_Mendoza wrote:

...

From the dumped file, it seems those strings are not null-terminated, not compliant with C's string. If GUI API allows you to assign the length of string that is not null-terminated, make sure the length parameter is correct.

...

To clarify, the strings you are referring to are strings in the memory allocated to emWin.

They are not the strings that I am passing to the emWin API.

The emWin _setText funtions do not take a length

BUTTON_SetText(BUTTON_Handle hObj, const char * s);‍‍‍‍‍

so I am not sure what you mean.

I have been mostly referring to this document 

https://www.nxp.com/docs/en/user-guide/UM03001_emWin5_5.pdf 

I originally thought it might have been to do with termination so I tried using strings with extra termination like this

const char line0[] = "AAAAAAAA\0\0";
TEXT_Handle hItem = getItem(ID_TEXT_1);
TEXT_SetText(hItem, line0);‍‍‍

and I found that the problem still happened.

A line taken from the original code that I attached

LISTBOX_AddString(hItem, "Item 0 here");‍‍

results in

0xA00E1440 54 00 74 65 6d 20 30 20 68 65 72 65 00 d3 f6 00 24 00 00 00 14 00 00 00 1c 00 00 00 13 00 00 00 00 00 00 00 54 14 0e a0 bc 10 0e a0 1c 00 00 00 15 00 00 00 24 00 00 00 00 00 0d 00 0d 00 00 00 T.tem 0 here.Óö.$...................T.. ... ........$...........‍‍

being in the block of memory allocated to emWin.

As you can see the string has been copied into the emWin memory with a NULL at the start before the rest of the string.

On my display I obviously don't see any string in that listbox item because it is corrupted.

Thanks

Elliot