FX3 ThreadX debug - application threads locked in active state

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
charlie
Level 1
Level 1
5 replies posted 10 sign-ins 5 sign-ins

Hello,

I ran into a situation where all the application threads are unresponsive.  

Using tx_thread_info_get() in the DMA callback of the CDC interface this is what it looks like:

charlie_0-1633042504394.png

The Slave_FIFO_sync, main_thread, gpif_thread, usb_thread and Heartbeat threads are all stuck in state 0(active) and unresponsive.

Since FX3 is a single threaded CPU, I'm curious how this can happen?

How can I go about debugging this? Any ThreadX features I can query for details?

Thanks you!

 

 

 

0 Likes
1 Solution

Hello,

Fortunately, we figured out what the problem was after attaching a JTAG probe.

It turns out we had a while(1) loop on the gpif_thread due to a corner case and the thread was running continuously without giving up its time.

The OS didn't have time to run and all the other threads ended up in TX_READY state (0).

-Charlie

 

 

View solution in original post

0 Likes
4 Replies
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello,

To understand the application better please let me know how many application threads are defined in your firmware. From the debug prints, I understand that main_thread, slavefifo_sync, gpif_thread , usb_thread, heartbeat_thread, system_timer_thread all are not the application threads. Is my understanding correct?

Also, kindly confirm that blocking calls are not done inside the callback function. For example we do not suggest calling cyu3pdebugprint API inside a DMA callback 

Regards,
Rashi
0 Likes

Hello,

Slave_FIFO_sync, main_thread, gpif_thread, usb_thread and Heartbeat threads are the application threads that get stuck in state 0 (running). All the other are ThreadX/system threads.

Out application waits on bulk transfers from the host. It reads contents to get the FPGA commands. Then send them over GPIF and waits for responses. We use CyU3PDmaChannelGetBuffer() and CyU3PEventGet() / CyU3PEventSet() to keep the threads as sleepy as possible.

A little thread overview:

Slave_FIFO_sync - control the board LEDs (Visual feedback)
Heartbeat - post a debug print every 2s over the CDC BULK IN ep
gpif_thread - wait for GPIF manual_in DMA channel buffer (FPGA responses)
usb_thread - wait for USB manual_in DMA channel buffer (Host commands)
main_thread - process the USB commands and control FPGA behavior

We use the DMA callback CdcCallback() (CDC BULK OUT ep) to send commands to the firmware when the application is not used.

The callback runs on the DMA_THREAD. This is the expected behavior:

charlie_0-1633104654031.png

Could you recommend any debug options? For example: can we use tx_thread_stack_error_notify() to monitor for stack overflow corruption?

 

Thank you!

0 Likes
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello,

Thank you for the confirmation.

To understand the problem better please let us know when is the issue seen. When is the expected behavior seen? Is the issue seen every time the application is run?

Is it possible to disable slaveFIFO_thread and heartbeat_thread for debugging  purpose and check if the issue is still seen?

Also, confirm if SDK 1.3.4 is being used for your application.

Regards,
Rashi
0 Likes

Hello,

Fortunately, we figured out what the problem was after attaching a JTAG probe.

It turns out we had a while(1) loop on the gpif_thread due to a corner case and the thread was running continuously without giving up its time.

The OS didn't have time to run and all the other threads ended up in TX_READY state (0).

-Charlie

 

 

0 Likes