task not running contiously

ehtane wrote on Thursday, February 28, 2019:

hi ,

i have created three task with the priority as high ,normal and normal
task once execute once

rtel wrote on Thursday, February 28, 2019:

I’m afraid without more information nobody will be able to assist:
https://www.freertos.org/FAQ-how-to-use-the-FreeRTOS-support-forum.html

ehtane wrote on Friday, March 01, 2019:

hi ,

sorry for inconvienience
I am using STM32F429 discovery board with free RTOS

i have created two task ,one task which need to trasnmit the data as received data interrupt ,so i have created binary semaphore and it will wait forever and if received interrupt generated it release the task .
Second task is the sd card write task which should write the data every after 15 min and in this i have implemented if(xSemaphoreTake(semHandle, 1000 )) and it enter after 1 sec and increase the counter and when the counter reaches 900 it will write the data .

but this not happen so can you please guide me for the same

rtel wrote on Friday, March 01, 2019:

Please share a little of the code so we can see how the semaphore is
created, ‘given’ and ‘received’.

ehtane wrote on Friday, March 01, 2019:

hi,

please refer the attached code

ehtane wrote on Friday, March 01, 2019:

hi,

please refer the attached code

ehtane wrote on Monday, March 04, 2019:

hi
waiting for your reply

richarddamon wrote on Monday, March 04, 2019:

One big question looking at the code, does HAL_UART_Transmit return before the messge is sent, or does it just spin wait for the completion. If it spin waits (as seems common in the HAL code) then that task will hog the CPU.

I have found that much of the HAL code isn’t very friendly to the RTOS environment.

ehtane wrote on Tuesday, March 05, 2019:

hi richard ,

thanks for the respone i think it just spin and wait for the complletion so what is the best option
instead of hal_code

ehtane wrote on Tuesday, March 05, 2019:

hi
waiting for your reply .
One more query
1 .if one task is running and if interrupt occur and do some action ,the task does not resume again how do that ,sorry if i have some mistaken as i am new to freeRTOS

richarddamon wrote on Tuesday, March 05, 2019:

In my experiance, many manufactures ‘HAL’ type drivers aren’t designed well for use in real time OSes, as they will tend to use things like spin wait. Also they tend to be designed to make your program portable only between processors of that manufacturer, not over a wider set of processors. What I find works the best for me is to first design an device agnostic API for using such devices, and then writing a device specific driver that implements it. This driver might use the HAL code if it is suitable, or another low level driver, or one you self write based on looking at the supplied drivers. In my experiance, many serial drivers are based on you give them a message, that message is printed and the you can give a new message (but only after the first is sent), while I prefer a model where you give the driver a message, it is added to an internal queue, and starts printing it, and more characters can be added as you go. The first is an easier driver to write, the second is an easier driver to use, and tends to not block the task printing as much, which is good in an RTOS based application.

As to your second question, when an interrupt occurs, the processor will jump into the ISR for the interrupt, which should do some short action to handle the interrupt and then return. If done correctly, FreeRTOS will continue to run the highest priority task that is ready to run, and and if the ISR caused a higher priority task to become ready it will run, and continue to run until it blocks for something again. The issue with your program is that the serial task was higher priority, but because it was just spin waiting for the serial port, it continued to be ready to run for the whole time, so never blocked. When it got back to the Semaphore Take, the semaphore had been given by the message being done, so it just continued. If the serial driver properly used interrupt to send the message, as opposed to spin waiting for the port, then the serial task would block, and let your lower priority task run.

ehtane wrote on Wednesday, March 06, 2019:

thanks for the reply
i will try to implement as per your comment

ehtane wrote on Wednesday, March 06, 2019:

hi ,

  1. i have written one task want to be sure that semaphore will enter only after 1 sec ?? below is the code plz advice if it is correct
    void task_Write(void const * argument)
    {
    /* USER CODE BEGIN task_FlashWrite */

    uint8_t tickcount = 0;
    const TickType_t xPeriod = pdMS_TO_TICKS( 1000 ); //1000 ms

/* Infinite loop */
for(;:wink:
{
if(xSemaphoreTake(semFlashHandle, xPeriod ))
{

      }
      xSemaphoreGive(semFlashHandle);
      osDelay(1);
  }

}

richarddamon wrote on Wednesday, March 06, 2019:

xSemaphhoreTake(handle, period) will return after the SHORTER of period ticks or when the semaphore is given. Not positive about osDelay (as that isn’t part of FreeRTOS) but that will probably be a delay of 1 system ‘tick’ or maybe 1 ms (which may round down to 0 ticks).

ehtane wrote on Friday, March 15, 2019:

hi richard instead of xSemaphhoreTake(handle, period) i am generating freeRtos software timer using cubeMx but it is not working i have made sure that /* Software timer definitions. */

  1. ##define configUSE_TIMERS 1**
  2. ##define configTIMER_TASK_PRIORITY ( 2 )
  3. ##define configTIMER_QUEUE_LENGTH 10
  4. ##define configTIMER_TASK_STACK_DEPTH 256**

osTimerStart(myTimerFWriteHandle, 60000); has been written before osKernelStart(); it get stuck somewhere and oskernelstart() does not get called . but if i put manually the timer code it works???

rtel wrote on Friday, March 15, 2019:

osTimerStart(myTimerFWriteHandle, 60000); has been written before
osKernelStart(); it get stuck somewhere and oskernelstart() does not get
called .

If you are not getting as far as starting the kernel then it should be
easy for you to step through the code in the debugger and see where you
end up. Probably in an assert. Debugging before mutli-threading starts
is much simpler.

but if i put manually the timer code it works???

Sorry, not sure what that means.

ehtane wrote on Monday, March 18, 2019:

but if i put manually the timer code it works???

Without using cubeMx if i create the timer and start it ,it works ??

ehtane wrote on Monday, March 18, 2019:

hi richard,

below is the code when i debug it goes upto oskernel start(),and i put the breakpoint in timercallback01() it does not goes into it ?? plz if you can help me out
int main(void)
{
/* USER CODE BEGIN 1 */

/* USER CODE END 1 */

/* MCU Configuration----------------------------------------------------------*/

/* Reset of all peripherals, Initializes the Flash interface and the Systick. */
HAL_Init();

/* USER CODE BEGIN Init */

/* USER CODE END Init */

/* Configure the system clock */
SystemClock_Config();

/* USER CODE BEGIN SysInit */

/* USER CODE END SysInit */

/* Initialize all configured peripherals /
MX_GPIO_Init();
MX_DMA_Init();
MX_USART1_UART_Init();
MX_SPI1_Init();
MX_I2C3_Init();
MX_ADC1_Init();
MX_RTC_Init();
MX_TIM1_Init();
MX_USART3_UART_Init();
MX_USART2_UART_Init();
MX_IWDG_Init();
/
USER CODE BEGIN 2 */

/* Enable Uart1 Interrupt*/
__HAL_UART_ENABLE_IT(&huart1, UART_IT_RXNE); // enable idle line interrupt
__HAL_UART_ENABLE_IT(&huart1, UART_IT_TC); // enable idle line interrupt
HAL_UART_Receive_IT(&huart1, (uint8_t *)&Usart_1byte, sizeof(Usart_1byte));

/* Enable Uart2 Interrupt*/
__HAL_UART_ENABLE_IT(&huart2, UART_IT_RXNE);
__HAL_UART_ENABLE_IT(&huart2, UART_IT_TC);
HAL_UART_Receive_IT(&huart2,(uint8_t *)&gsmbyte, sizeof(gsmbyte));

/* Enable Uart3 Interrupt*/
__HAL_UART_ENABLE_IT(&huart3, UART_IT_IDLE); // enable idle line interrupt
__HAL_DMA_ENABLE_IT (&hdma_usart3_rx, DMA_IT_TC); // enable DMA Tx cplt interrupt
HAL_UART_Receive_DMA (&huart3, DMA_RX_Buffer, DMA_RX_BUFFER_SIZE);
hdma_usart3_rx.Instance->CR &= ~DMA_SxCR_HTIE; // disable uart half tx interrupt

__HAL_RCC_RTC_ENABLE();
/* USER CODE END 2 */

/* Create the mutex(es) /
/
definition and creation of uartMutex */
osMutexDef(uartMutex);
uartMutexHandle = osMutexCreate(osMutex(uartMutex));

/* USER CODE BEGIN RTOS_MUTEX /
/
add mutexes, … /
/
USER CODE END RTOS_MUTEX */

/* Create the semaphores(s) /
/
definition and creation of semUART1 */
osSemaphoreDef(semUART1);
semUART1Handle = osSemaphoreCreate(osSemaphore(semUART1), 1);

/* definition and creation of semGSM */
osSemaphoreDef(sem02);
sem02Handle = osSemaphoreCreate(osSemaphore(sem02), 1);

/* definition and creation of semFlash */
osSemaphoreDef(semFlash);
semFlashHandle = osSemaphoreCreate(osSemaphore(semFlash), 1);

/* definition and creation of myCountingSem01 */
osSemaphoreDef(myCountingSem01);
myCountingSem01Handle = osSemaphoreCreate(osSemaphore(myCountingSem01), 2);

/* USER CODE BEGIN RTOS_SEMAPHORES /
/
add semaphores, … /
/
USER CODE END RTOS_SEMAPHORES */

/* Create the timer(s) /
/
definition and creation of myTimer01 */
osTimerDef(myTimer01, Callback01);
myTimer01Handle = osTimerCreate(osTimer(myTimer01), osTimerPeriodic, NULL);

/* USER CODE BEGIN RTOS_TIMERS /
// __HAL_IWDG_START(&hiwdg);
osTimerStart(myTimer01Handle, 1000);
/
start timers, add new ones, … /
/
USER CODE END RTOS_TIMERS */

/* Create the thread(s) /
/
definition and creation of taskUart_1 */
osThreadDef(taskUart_1, task_UART, osPriorityHigh, 0, 128);
taskUart_1Handle = osThreadCreate(osThread(taskUart_1), NULL);

/* definition and creation of taksFlashWrite */
osThreadDef(taksFlashWrite, task_sdWrite, osPriorityNormal, 0, 128);
takssdWriteHandle = osThreadCreate(osThread(takssdWrite), NULL);

/* definition and creation of myTask03 */
osThreadDef(myTask03, task_03, osPriorityBelowNormal, 0, 128);
myTask03Handle = osThreadCreate(osThread(myTask03), NULL);

/* USER CODE BEGIN RTOS_THREADS /
/
add threads, … /
/
USER CODE END RTOS_THREADS */

/* USER CODE BEGIN RTOS_QUEUES /
/
add queues, … */

/* USER CODE END RTOS_QUEUES */

/* Start scheduler */
osKernelStart();

rtel wrote on Monday, March 18, 2019:

Unfortunately none of this is using the native FreeRTOS API, so I can’t
be sure of the relative priorities. It looks like taskUart_1 is the
highest priority task that you create. If you put a break point in
there, does it get hit? Does that have a priority above the timer task
priority? If you put a break point at the start of the timer task
(prvTimerTask() in FreeRTOS/source/timers.c), does that get hit?