cancel
Showing results for 
Search instead for 
Did you mean: 

Threads get suspended forever after calling tx_thread_sleep() [SOLVED]

NguyenG
Associate

Hi everyone,

I'm trying to create an example following this article. I'm using the STM32F429I-DISC1 evaluation board and using X-CUBE-AZRTOS-F4.1.0.0 software package.

https://community.st.com/s/article/how-to-create-a-thread-using-azurertos-and-stm32cubeide

I have one problem that the thread gets suspended forever when calling the tx_thread_sleep(ULONG timer_ticks) function. My source code and configuration is basically the same as that in the article. Do you guys have any idea what's the problem is?

For your information, I create a TX_TIMER in parallel to interrupt every 10 ticks to check if the system tick timer is running. The timer is created successfully (return TX_SUCCESS), but unfortunately it doesn't run either. When I delete tx_thread_sleep(), everything, including the timer, works normally.

I also try to create two threads A and B. Both can only run once and get suspended forever. And it works when I delete the tx_thread_sleep().

VOID my_thread_entry(ULONG initial_input)
{
	TX_THREAD* thread_info = tx_thread_identify();
	while(1){
		printf("\r\nThis is Thread %s", thread_info->tx_thread_name);
		tx_thread_sleep(1);
	}
}

Thanks in advance,

Giang

1 ACCEPTED SOLUTION

Accepted Solutions
NguyenG
Associate

Hi Walid,

Thanks for your support, the problem is now solved!

I have imported the project configuration from the example Tx_Thread_Creation for board NUCLEO-F429ZI, and it works as expected. I also tried to use my own source code (only the parts that I change in main and app_threadx files), and it works without any problem.

The thing is I encounter the very same problem with tx_thread_sleep() when I create a new STM32 project with the board selector. However, when I create a new project with MCU/MPU Selector to choose STM32F429ZI, following the same steps and using the same source codes, there is no problem at all. I think it has something to do with the board configuration step.

Updated: when I create a new project with board selector, if I choose to initialize all peripherals with their default mode (and clear pinout later), tx_thread_sleep() works normally. If I choose otherwise, the problem arises again.

Best regards,

Giang

View solution in original post

6 REPLIES 6

Hello @NguyenG​ 

You can refer to the following examples. You can port them to you board and customize them to your needs.

Please let me know if your problem has been resolved.

BeST Regards,

Walid

NguyenG
Associate

Hi Walid,

Thanks for your support, the problem is now solved!

I have imported the project configuration from the example Tx_Thread_Creation for board NUCLEO-F429ZI, and it works as expected. I also tried to use my own source code (only the parts that I change in main and app_threadx files), and it works without any problem.

The thing is I encounter the very same problem with tx_thread_sleep() when I create a new STM32 project with the board selector. However, when I create a new project with MCU/MPU Selector to choose STM32F429ZI, following the same steps and using the same source codes, there is no problem at all. I think it has something to do with the board configuration step.

Updated: when I create a new project with board selector, if I choose to initialize all peripherals with their default mode (and clear pinout later), tx_thread_sleep() works normally. If I choose otherwise, the problem arises again.

Best regards,

Giang

MR7
Associate II

Hello

I am having the same problem with STM32F411Discovery and I could solve the problem in the same way but I would like to know the reason that is causing this problem in case I face with it in the future. Did you identify it?

Thanks in advance

Thanks for the help! I had the same issue, but as you pointed out it was fixed by creating a new project starting from the CPU instead of the board.

It seems it was the NVIC "Priority Group" setting that was wrong. It must be set to "4 bits for pre-emption priority, 0 bits for sub-priority". The default when starting from a board is "0 bits, 4 bits".

I think the root cause is that the Azure/ThreadX RTOS init code for the interrupt priorities in tx_initialize_low_level.s assumes "4, 0" bits, and does not handle any other case (?) But I haven't dug into this in detail. The HAL on the other hand seems to use the actual setting when writing to the priority registers.

The NVIC "Priority Group" setting is found in the STM32CubeIDE graphical pinout window (for the .ioc file), in the "System Core / NVIC" section. If it was set to "0, 4", then the "Time base" preemption priority should probably also be changed to 15 when setting it to "4, 0".

 

Screenshot 2024-03-13 232056.png

 

Screenshot 2024-03-13 232257.png

Hi JSmith,

 

The solution you provided worked. I was facing the same issue but after changing the preemption priority to 15 and the priority group to 4, it started resuming the task after the required delay. 

 

Thanks

Thanks, good to hear!