cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with thread startup after power cycle on embedded application

LadyMt
Associate III

Hello,

My application is loaded via flash memory. Four threads are created and they seem to be generated correctly because when the board is connected to the computer, all the threads run well. But if I disconnect the power and then turn it back on, the threads no longer run.

Systick is used for ThreadX and TIM6 is used for HAL-Tick.

But the scheduler does not start the threads. I do not understand why. I am new to threads.

Has anyone encountered a similar problem and have solutions to suggest? Please

I am attaching the file app_thread.c

13 REPLIES 13
AScha.3
Chief III

Hi,

i think, this has nothing to do with threads.

Just make a simple test program, just flashing a LED (if you have one there on a pin). no RTOS/thread .

Use same clock tree setting and flashing mode.

Then check: is this program running after power cycle ?

If you feel a post has answered your question, please click "Accept as Solution".

Thanks for your reply.

Before calling MX_ThreadX_Init();

void MX_ThreadX_Init(void)
{
  /* USER CODE BEGIN  Before_Kernel_Start */

  /* USER CODE END  Before_Kernel_Start */

  tx_kernel_enter();

  /* USER CODE BEGIN  Kernel_Start_Error */

  /* USER CODE END  Kernel_Start_Error */
}

in the main.c file, I make the leds blink and on startup it does. But after MX_ThreadX_Init(), nothing happens

That is to be expected as tx_kernel_enter() never returns if it starts correctly. Note the comments for user code after tx_kernel_enter(). It is only reached if there is an error starting the kernel.

One thing to try in your threaded application is to blink a LED in the Kernel_Start_Error section to indicate an error starting the kernel.

How is the board powered when it is disconnected from the computer?

I placed the code to make the LED blink in the section /* USER CODE BEGIN Kernel_Start_Error */ and the LED does not blink when powered on. Therefore, the kernel startup is functioning properly.

The board is powered by mains (it is an internal development board for the company). BOOT0 is set to 0.

Do you have any other troubleshooting suggestions?please

Ok,

so

1. make a simple test program, no rtos, as i wrote. Just blink the LED...success ?

2. with htos, put the simple LED-blink in a thread, maybe the first that rtos gives you as your new "main" .

 

In both cases you should get the same : LED blinking.

Just using for the delay HAL_delay() for simple test without rtos , but the delay for your rtos , maybe like this:

  
     for( ;; )
     {
         /* Simply toggle the LED every 500ms, blocking between each toggle. */
         ToggleLED();
         tx_thread_sleep(50); 
     }

 

If you feel a post has answered your question, please click "Accept as Solution".

@AScha.3 : I did the two tests, and in both cases, it works really well when powered on. 

 

In my situation, I want to manage 4 threads. So, after conducting the tests you recommended on one thread, I tried doing the same on all 4 threads, and it also worked. Therefore, the problem must be related to what I am doing inside the threads. However, I don't understand why it doesn't work upon powering on without having to re-upload the code.

 

 

 

 

LadyMt
Associate III

@AScha.3

I am waiting for data from UART9 using HAL_UART_Receive_DMA(), and this data is processed within the threads. Now, I am starting to think that the interrupt system is not active after powering on.

Would you like me to provide a potential troubleshooting approach or steps to diagnose and fix this issue?

 

  /* USER CODE BEGIN 2 */
	HAL_UART_Receive_DMA(&huart9, rx_data, 1);
	HAL_TIM_PWM_Start(&htim1, TIM_CHANNEL_1);
	HAL_TIM_Base_Start(&htim2);
  /* USER CODE END 2 */

  MX_ThreadX_Init();
LadyMt
Associate III

To make it work, I replaced

HAL_UART_Receive_DMA(&huart9, rx_data, 1);

with

HAL_UART_Receive_IT(&huart9, rx_data, 1);

and now it works very well.

I don't understand why using DMA on power-up causes the UART not to activate. Do you have any idea?

>I did the two tests, and in both cases, it works really well when powered on.

 

GOOD !

 

+

>that the interrupt system is not active after powering on

If you dont stop it - it IS active .

--- as you set it in Cube -> nvic settings (priority, active or not ---check this. )

AScha3_0-1722512294443.png

Just make the priority ranking with some sense - and the Azure sys timer is handeled by itself, you cannot change its settings. (TIM6 or whatever you give it...)

 

If you feel a post has answered your question, please click "Accept as Solution".