TouchGFX display glitch after power off-on, but not after flash build.

[MM..1]

I test app on U599. GUI task priority set little low as hw task. After flash all works ok, but after powering start gui glitch on SVG fade animation or other redraw.

After swap priority GUI up all works ok. Why this after flash difference occurs?

[GaetanGodart]

Hello @MM..1 ,

If it is on the STM32U599-DK, could you share the project so we can test it?

Regards,

[MM..1]

No DK, custom board and LCD.

[GaetanGodart]

Hello @MM..1 ,

I was expecting that :\

Did you test performances?
When you redraw your SVG, what is the performance (after build and after reset)?

I don't understand this: "After swap priority GUI up all works ok"
You have changed the priorities and now it works? After build and after reset?

Regards,

[MM..1]

/* Definitions for defaultTask */
osThreadId_t defaultTaskHandle;
const osThreadAttr_t defaultTask_attributes = {
  .name = "defaultTask",
  .priority = (osPriority_t) osPriorityAboveNormal,
  .stack_size = 4096 * 4
};
/* Definitions for hwTask01 */
osThreadId_t hwTask01Handle;
const osThreadAttr_t hwTask01_attributes = {
  .name = "hwTask01",
  .priority = (osPriority_t) osPriorityAboveNormal1,
  .stack_size = 1024 * 4
};

default is TouchGFX = as you see lower prio by 1, result after build and flash ok, but after power glitch
FYI (hwtask use HAL I2C pool)

/* Definitions for defaultTask */
osThreadId_t defaultTaskHandle;
const osThreadAttr_t defaultTask_attributes = {
  .name = "defaultTask",
  .priority = (osPriority_t) osPriorityAboveNormal2,
  .stack_size = 4096 * 4
};
/* Definitions for hwTask01 */
osThreadId_t hwTask01Handle;
const osThreadAttr_t hwTask01_attributes = {
  .name = "hwTask01",
  .priority = (osPriority_t) osPriorityAboveNormal1,
  .stack_size = 1024 * 4
};

with this works without glitch. 

Now i rework hwtask code to use I2C DMA send with semaphores and both combinations of priority seems works ok anyway.

Still question why first combination show issues only after power off.

[GaetanGodart]

I am glad that you found a solution that works!

After a reset, issues can arise such as:

• Task priorities might cause higher-priority tasks to block others, leading to starvation or deadlocks
• Stack overflows can corrupt memory if tasks don’t have enough stack space
• Hardware or peripherals may not be fully re-initialized, causing unexpected behavior
• Global/static variables might retain unexpected values if not properly reset
• Watchdog timers or fault handlers might trigger if tasks misbehave after reset

Making sure priorities are set correctly, stacks are sized well, and initialization routines run fully after reset usually resolves these problems.

Regards,