Azure GUIX thread _gx_system_thread cannot be scheduled after running for hours

SQ Jin 16 Reputation points
2022-11-09T09:50:26.47+00:00

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
258630-gx-queue.jpg

A breakpoint is put to _gx_system_thread and code not stop when _gx_system_event_queue is full
258731-gx-thread.jpg

Could you give some suggestion to locate the issue.

Azure RTOS
Azure RTOS
An Azure embedded development suite including a small but powerful operating system for resource-constrained devices.
333 questions

10 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Ken Maxwell 706 Reputation points Microsoft Employee
    2022-11-09T21:35:29.177+00:00

    Hello @SQ Jin ,

    That's good information. Thread state (0) means the thread is running or ready to run, it's not suspended. So the only things I can think of are 1) the thread is in an infinite loop somewhere, and never gets back to pull the next event from the queue or 2) A thread of higher priority is running and not allowing the GUIX thread any CPU time. A few other things I am curious about are a) what sort of events are filling the GUIX event queue? Are these just touch and timer events that GUIX is not popping from the queue? and b) Can you go through your other threads and see what other threads might be running at higher priority and blocking the GUIX thread?

    You might also put a breakpoint at the end of the function _gx_system_thread_entry, where we call _gx_system_error_process and return. If some sort of error is happening and causing the GUIX thread to terminate that might also explain the situation you are seeing.

    Let me know what you find out. We haven't had a report like this to my knowledge so I don't think there is a structural problem but you can never say never.

  2. Ken Maxwell 706 Reputation points Microsoft Employee
    2022-11-11T22:06:19.7+00:00

    @SQ Jin the only thing I can think of in this case is that the GUIX thread is stuck in an endless loop. When you break in with the debugger where is the program counter?

    0 comments
  3. Ken Maxwell 706 Reputation points Microsoft Employee
    2022-11-11T22:13:18.14+00:00

    @SQ Jin one more question, are you calling any of the GUIX APIs from threads outside the GUIX system thread? It's OK if you are, but it might help to understand why your UI is getting locked up.

  4. Ken Maxwell 706 Reputation points Microsoft Employee
    2022-11-16T00:31:52.59+00:00

    @SQ Jin Can you tell me the values of _tx_thread_current_ptr and _tx_thread_execute_ptr please?

  5. Ken Maxwell 706 Reputation points Microsoft Employee
    2022-11-16T14:42:01.373+00:00

    @SQ Jin thanks for the additional information. I have someone else on my team looking at this as well. So far we don't see anything obvious. Did you place a breakpoint at the end of the gx_system_thread_entry function to make sure the thread is not terminating? Also, could you try bumping the stack size to 8K, just for a test? I don't think this has anything to do with the problem but it's simple enough to try it.

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.