Azure GUIX thread _gx_system_thread cannot be scheduled after running for hours

Question

Hi

I'm using ThreadX + GUIX on STM32H743 MCU.

ThreadX config:
TX_ENABLE_FPU_SUPPORT,
TX_INCLUDE_USER_DEFINE_FILE,
TX_CORTEX_M_EPK, TX_PORT_USE_BASEPRI,
TX_PORT_BASEPRI=10,
TX_EXECUTION_PROFILE_ENABLE,

GUIX using defualt config.

ThreadX and GUIX version is 6.1.10, compiler is ARM AC6.

The issue is, when the app run for serval hours, UI will stop responding touch event for internal timer event. While other thread is still working. LED is blinking, uart can receive/send data, touch interrupt still works and i can still read touch infomation from touch IC in touch thread.

I have checked the _gx_system_event_queue, the queue is full but suspend_list is 0, suspend_count is 0

A breakpoint is put to _gx_system_thread and code not stop when _gx_system_event_queue is full

Could you give some suggestion to locate the issue.

Answer 1

@SQ Jin I have attached a modified version of the function gx_system_event_fold(). We haven't ever seen a problem here, but just to eliminate this possibility I ask you to try temporarily replace this function in your GUIX library build. The modified version simply calls gx_system_event_send, rather than modifying the existing event if a match is found. Just because you seem to be having some sort of queue corruption problem I want to eliminate this possibility. Please rename the attached file to gx_system_event_fold.c (the system won't allow attaching .c files), and re-build your guix library with this file. Thanks

Answer 2

@SQ Jin could you send me your Touch_scan thread, or explain what's happening with the thread-resume/event flags get/internal suspend that is happening after each event is pushed to the GUIX event queue? Thanks!

Answer 3

@SQ Jin thank you for sending the trace data file. We are still looking into it trying to understand what is going on. I'm not sure what you mean by your assertion "only two touch message send to the GUIX message queue". What I see is many many touch messages have been sent to the GUIX message queue by the time we get to event 2600. Also, it looks like each time the GUIX thread wakes up (unblocks waiting for an event) it only typically processes one or two events, then blocks again because the queue is empty. So the GUIX thread is not getting far behind, which is what I somewhat expected to see. I'm not sure why the green "Running" icon is shown in the GUIX System Thread when things go awry, but this seems to be key to understanding what is going wrong. Up to this point, the R icon only shows up in the Idle loop.

We might need to have you add some variables for debugging and let us know what you find. Let me get back to you on that.

Answer 4

Logging on the time when GUIX cannot scheduled USING TraceX is successed.

As the picture show, when GUIX working abnormal, only two touch message send to the GUIX Message queue, then it seems that queue is full and no more message can put into the queue. Scheduler also have something wrong so that GUIX thread cannot executed anymore.

Attached link is the TraceX log ：https://1drv.ms/u/s!Ag2tNyGcvSgmmHeb1RphQBeuHdhR

Answer 5

Hi @SQ Jin

When context for each thread is saved, the PC is saved to the thread's stack. Can you look into the _gx_system_thread stack and let us know where in the _gx_system_thread the PC is pointing to.

I assume you are using the SysTick timer. Is it still running when you get into this situation? Do you see _tx_timer_system_clock incrementing? Can you step through the _tx_timer_interrupt function? The _gx_system_thread has a time slice, so within 10 ticks, the time slice processing should occur and the _gx_system_thread should be resumed. What do you see happening?