System go in MemManage_Handle

Hi All,

NXP RT1166 with McuXpresso 11.6 SDK 2.12.1 LVGL8.2 GUI Guider nxp 1.4.1

Update every second 2 labels on the screen

I use from FreeRtos the brief FreeRTOS tick hook to create every sec a flag = 1 .

Every sec write to the labels.

Code to reproduce

Use
lv_label_set_text(guider_ui.Base_label_Tempcap,“12,3”);
lv_label_set_text(guider_ui.Base_label_Tempcool,“20,’”);
Add the relevant code snippets here.

/You code here/

static void AppTask(void *param)
{
#if LV_USE_LOG
lv_log_register_print_cb(print_cb);
#endif

int8_t hv_buf[64];
uint16_t hv16;
uint16_t hvuint;
uint32_t hv_long;
uint8_t hv;
double test_float,test_float1;
double hvuint_double;
uint16_t Cal_Sec_Meas_Charts;
uint16_t loop;
uint8_t Flag_ScreenMeas_Act;

lv_port_pre_init();
lv_init();
lv_port_disp_init();
lv_port_indev_init();

s_lvgl_initialized = true;

setup_ui(&guider_ui);
events_init(&guider_ui);
custom_init(&guider_ui);




for (;;)
{

 if(Flag_GUI)
   	{
	Flag_GUI = 0;
	lv_task_handler();

	}

if((Flag_Update_Screen) && lv_obj_is_valid(guider_ui.Base))
	{
	Flag_Update_Screen = 0;
	 Test_Uart('t');

	       			Flag_Sec = 0;
	       			if(sw)
	       			{
	       				sw = 0;
	       				lv_label_set_text(guider_ui.Base_label_Tempcap,"20,3 C");
	       				lv_label_set_text(guider_ui.Base_label_Tempcool,"21,5 C");
	       			}
	       			else
	       			{
	       				sw = 1;
	       				lv_label_set_text(guider_ui.Base_label_Tempcap,"34,8 C");
	       				lv_label_set_text(guider_ui.Base_label_Tempcool,"31,7 C");
	       			}
	
	}

}

}


At lv_conf.h
#if LV_MEM_CUSTOM == 0
/* Size of the memory available for `lv_mem_alloc` in bytes (>= 2kB)*/
#define LV_MEM_SIZE (128U * 1024U + 720 * 1280 * 4)

## Screenshot and/or video
If possible, add screenshots and/or videos about the current state.

The two labels will be updated .
After a few minutes the system crash at MemManage_Handle
Debugged in SDRAM memory -> same result.

No overload at Stackmemory
Only 15 % of SDRAM is in use.

If i don't update the labels every sec , the system run for 24 hours.
Why crashed the  system ?
Tested the whole SDRAM for 24 hours withous aly fault.
Tested the flash without any fault.
Tested the cache memory without any fault.

With mcuXpresso 11.5 SDK2.11.1 Gui Guider 1.3.1 the system run for 24 hours without any crash.

Where can i look after?

With regards
Paul

Hi @Paul_B ,

Here is a suggestion, I don’t have any knowledge of GUI Guider but hopefully this will be of some help…

Have you verified the objects guider_ui.Base_label_Tempcap and guider_ui.Base_label_Tempcool have been created and the variables have been declared in an accessible scope.

It might be worth changing:

to something like:

if((Flag_Update_Screen) && lv_obj_is_valid(guider_ui.Base_label_Tempcap) && lv_obj_is_valid(guider_ui.Base_label_Tempcool))

This will hopefully stop the crash if the text objects don’t exist for any reason.

Kind Regards,

Pete

Hi Pete,

The Gui Guider nxp create the source code for implementing in mcuXpresso.
Ik changes the if line by

if((Flag_Update_Screen) && lv_obj_is_valid(guider_ui.Base_label_Tempcap) && lv_obj_is_valid(guider_ui.Base_label_Tempcool))

I see every second , the labels changed .
After about a minute the system crashed also.
Any other ideas ?

With regards
Paul

Hi @Paul_B ,

The next thing I would look into is whether you have sufficient stack allocated for your tasks. Maybe double the stack size for the AppTask as a quick test. If you are using FreeRTOS you can enable stack checking in the FreeRTOSConfig.h file by adding this line:

#define configCHECK_FOR_STACK_OVERFLOW			2		// This introduces task overhead in kernel so only enable when trouble is brewing!

It might be worth enabling assert as well if it is not enabled, this may give you some clue as it might be able stop the execution of the code before the crash. This is also enabled in FreeRTOSConfig.h as far as I can remember by the following lines:

void vAssertCalled( const char * pcFile, unsigned long ulLine );
#define configASSERT( x ) if( ( x ) == 0 ) vAssertCalled( __FILE__, __LINE__ );

It is also worth checking and making sure you have sufficient heap memory allocated also.

Hope that helps.

Kind Regards,

Pete

Hi Pete,

Checked in FreeRTOSConfig.h

#define configCHECK_FOR_STACK_OVERFLOW 1
#define configMINIMAL_STACK_SIZE ((unsigned short)90)

/* Define to trap errors during development. */
#define configASSERT(x) if((x) == 0) {taskDISABLE_INTERRUPTS(); for (;;);}

Besides this, we already put extra stacksize

stat = xTaskCreate(AppTask, “lvgl”, configMINIMAL_STACK_SIZE + 512, NULL, tskIDLE_PRIORITY + 2, NULL);

With regards

Any other ideas?

With regards
Paul

Hi @Paul_B ,

Your assert implementation looks fine.

You can also enable the detailed logging in LVGL. Look in the lv_conf_template.h file for all possible options for your version.

You can also enable all the asserts in LVGL in the lv_conf.h again look at the lv_conf_template.h file for all possibilities for your version. See example below:

/*Enable asserts if an operation is failed or an invalid data is found.
 *If LV_USE_LOG is enabled an error message will be printed on failure*/
#define LV_USE_ASSERT_NULL          1   /*Check if the parameter is NULL. (Very fast, recommended)*/
#define LV_USE_ASSERT_MALLOC        1   /*Checks is the memory is successfully allocated or no. (Very fast, recommended)*/
#define LV_USE_ASSERT_STYLE         1   /*Check if the styles are properly initialized. (Very fast, recommended)*/
#define LV_USE_ASSERT_MEM_INTEGRITY 1   /*Check the integrity of `lv_mem` after critical operations. (Slow)*/
#define LV_USE_ASSERT_OBJ           1   /*Check the object's type and existence (e.g. not deleted). (Slow)*/

Whilst this will likely slow things down to a crawl you might be able to spot the problem more easily, it may take much longer to crash though…

Apart from this in my experience these types of problems are always caused by some form of heap or stack related memory corruption or a something not being initialised correctly.

When the system crashes can you see the call stack in your debugger so you can judge exactly where the program is crashing?

Are there any other tasks running? If yes I would check these also. The program may crash when you enable the update of the labels but the problem may be else where and is only brought to light when the label task is running.

Perhaps if there is an NXP forum it may be worth a post there too?

Kind Regards,

Pete

Hi Pete,
The LV_USE_LOG was already set to 1 , i set the LV_USE_DEBUG to 1 for activating the printing failure

#define LV_USE_LOG 1

#define LV_USE_DEBUG 1 //0

#if LV_USE_DEBUG
#define LV_USE_ASSERT_NULL 1
#define LV_USE_ASSERT_MEM 1
#define LV_USE_ASSERT_MEM_INTEGRITY 0
#define LV_USE_ASSERT_STR 0
#define LV_USE_ASSERT_OBJ 1 //0
#define LV_USE_ASSERT_STYLE 1 //0
#endif /* LV_USE_DEBUG */

At starup , i get the following message:

SEGGER J-Link GDB Server V7.66e - Terminal output channel
Succes to create lvgl task
[Warn] (0.000, +0) lv_init: Object sanity checks are enabled via LV_USE_ASSERT_OBJ which makes LVGL much slower (in lv_obj.c line #160)

[Warn] (0.000, +0) lv_init: Style sanity checks are enabled that uses more RAM (in lv_obj.c line #164)

After a minute , the system crashed with BusFault_Handler without any message from lv log .

I think that the debugger leads the programexit to the WEAK_AV void BusFault_Handler(void) before lvgl could jump to the lv_log_register_print_cb and printout a message.

Tried again and get an MemManage_Handler fault
See screenshot in attachment.

With regards
Paul

Hi Pete,

There is no other task running.
When the system crashes , the call stack is within his address range .
Heap → 35 % used
Main stack 0.98 % used.
We also posted at the NXP forum, they have so must problems to solve that we have te be patient !!

When we used mcuXpresso 11.5 and Gui Guider nxp 1.3.1 , we didn’t had this problem .
Only the system crashed when we changed the screen from an second screen to a thirth screen !!

How can i send you the screenshot ?

With regards
Paul

Hi Pete,
I expanted the extra stacksize for the FreeRtos tast from 512 to 2048 .
Still crashed , with extra stacksize it doesn’t take longer before is crashes.

With regards
Paul

Hi @Paul_B ,

I would go ahead and enable the MEM and STR defines also nothing to loose:

#define LV_USE_ASSERT_MEM_INTEGRITY 1
#define LV_USE_ASSERT_STR 1

It’s hard to speculate much more what maybe going on, all you can do is make sure your variables are declared in the correct scope and initialised correctly. You can also annotate the code as much as possible as you have been already (ie outputing characters to the serial port at certain points) and see if you can catch the point where things are going wrong.
You should be able to upload screenshots as image files using the upload button in the edit box here or you can send me files directly at petebone00@gmail.com if that is not working for any reason.

Kind Regards,

Pete

Hi Pete,

I have put these 2 defines at ‘1’ .
I also use the lv_mem_monitor function to display the RAM behavior.

a list from start to crash:
[Warn] (0.000, +0) lv_init: Memory integrity checks are enabled via LV_USE_ASSERT_MEM_INTEGRITY which makes LVGL much slower (in lv_obj.c line #156)

[Warn] (0.000, +0) lv_init: Object sanity checks are enabled via LV_USE_ASSERT_OBJ which makes LVGL much slower (in lv_obj.c line #160)

[Warn] (0.000, +0) lv_init: Style sanity checks are enabled that uses more RAM (in lv_obj.c line #164)

used: 25128 ( 1 %),frag: 1 %, biggest free:3791740
used: 25128 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740
used: 24612 ( 1 %),frag: 1 %, biggest free:3791740

With regards
Paul

Hi @Paul_B ,

In the screen shot it is only possible to see the last two entries in the call stack MemManage_Handler followed by <signal handler called> is there anything listed after those entries?

I have the MCUXpresso IDE v11.6.0 [Build 8187] [2022-07-13] NXP IDE on my laptop which I installed to help out someone else, but I don’t have any hardware as I work in the FPGA arena. If you want me to take a detailed look you can export your project and email it to me directly, you would also need to log into your NXP account and share your SDK download with me so I can install that as well. The offers there if you want me to have a look over it.

Kind Regards,

Pete

Hi Pete,
At a second screen “Settings” , there is a digital clock created.
When I go to this second screen , the secondscounter start from ‘0’ .
At this screen , the clock counter counts every second and is not crashing!!!
The difference here is that the updating of the values in the clock setting are fully done by lvgl.
No softwarelines are implemented from me to update the clockvalues.

With regards
Paul