Hello,
This is my first post in this forum. haha.
Im using stm32f107vc on easymxprov7 board with mikroC IDE. My freeRTOS is v9.0.0 provided by mikroC. Currently i have a problem using xTaskGenericNotifyFromISR for my USART1. The program stuck and my LED task does not blink. But when I changed to xTaskGenericNotify which it should not be called in ISR, its works. Im confused right now.
Thanks in advanced.
Please post the code.
This is my code for ISR
void UARTDebug_RxInterrupt_Isr
{
UBaseType_t xHigherPriorityTaskWoken = pdFALSE;
if(UARTDebug_RxInterrupt_Flag)
{
UARTDebug_cRx0 = UARTDebug_GetChar();
switch(UARTDebug_IsrState)
{
case 0:
if (UARTDebug_IsrCt > UARTDebug_Buffer_Length)
{
UARTDebug_IsrCt = 0;
}
else if(UARTDebug_cRx0 == '\r')
{
UARTDebug_IsrState = 1;
}
else
{
UARTDebug_IsrBufferData[UARTDebug_IsrCt++] = UARTDebug_cRx0;
}
break;
case 1:
if(UARTDebug_cRx0 == '\n')
{
UARTDebug_IsrBufferData[UARTDebug_IsrCt] = 0;
UARTDebug_IsrCt = 0;
UARTDebug_IsrState = 0;
//RTOS
//xTaskGenericNotify(xCmd_TaskHandle, NULL, eNoAction, &xHigherPriorityTaskWoken);
xTaskGenericNotifyFromISR(xCmd_TaskHandle, 0, eNoAction, NULL, &xHigherPriorityTaskWoken);
}
else
{
UARTDebug_IsrBufferData[0] = 0;
UARTDebug_IsrBufferData[1] = 0;
UARTDebug_IsrCt = 0;
UARTDebug_IsrState = 0;
}
break;
default:
break;
}
UARTDebug_RxInterrupt_Clr;
//TX LPUSART ECHO TEST
//UARTDebug_PutChar(UARTDebug_cRx0);
//if above freeRTOS API wakeup any higher priority task, then yield the processor
//to higher priority task which is just woken up.
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}
}
This is my code from task notify received
void Cmd_Task(void* pvParameters)
{
char Cmd_SendBuffer[Cmd_Buffer_Size];
char Cmd_ReplyBuffer[Cmd_Buffer_Size];
uint16_t Cmd_Reply_Length;
uint8_t Cmd_ProcessState = 0;
uint8_t Result;
while(1)
{
//USART1_PutString("Cmd_Task\r\n");
switch(Cmd_ProcessState)
{
case 0:
while(xTaskNotifyWait(0, 0, NULL, 10) != pdPASS);
Cmd_ProcessState = 1;
break;
case 1:
if(Cmd_BusyStatus == Cmd_Busy_None)
{
Cmd_BusyStatus = Cmd_Busy_Debug;
Cmd_ProcessState = 2;
}
break;
case 2:
//taskENTER_CRITICAL();
NVIC_IntDisable(IVT_INT_USART1); //Input Cmd
//xSemaphoreTake( xUARTDebug_Mutex, portMAX_DELAY );
sprintf(Cmd_SendBuffer,"%s",UARTDebug_IsrBufferData); //Cmd_Send
memset(UARTDebug_IsrBufferData, NULL, UARTDebug_Buffer_Size);
Result = Cmd_Process((uint8_t *)Cmd_SendBuffer, &Cmd_ReplyBuffer[0]);
if(Result == 1)
{
Cmd_ProcessState = 4;
}
else if(Result == 2)
{
Cmd_Reply_Length = strlen(Cmd_ReplyBuffer);
}
else if(Result == 3 || Result == 4)
{
Cmd_Reply_Length = strlen(Cmd_ReplyBuffer);
Cmd_ReplyBuffer[Cmd_Reply_Length] = 0;
Cmd_ProcessState = 3;
}
//taskEXIT_CRITICAL();
NVIC_IntEnable(IVT_INT_USART1);
//xSemaphoreGive( xUARTDebug_Mutex );
break;
case 3:
if(xQueueSend(xUARTDebug_Queue, Cmd_ReplyBuffer, 0) == pdTRUE)
{
}
Cmd_ProcessState = 4;
break;
case 4:
Cmd_BusyStatus = Cmd_Busy_None;
Cmd_ProcessState = 0;
break;
default:
break;
}
}
}
This is when im using “TaskNotifyFromISR”. But when I change to TaskNotify, its works.
Thanks in advanced.
During debug, it goes to “configASSERT(ucCurrentPriority >= ucMaxSysCallPriority);”
This is my config “configMAX_SYSCALL_INTERRUPT_PRIORITY 0x30” & “NVIC_SetIntPriority(IVT_INT_USART1, _NVIC_INT_PRIORITY_LVL1);”
I set the USART1 to lvl1 because when i enter criticalTask, the ISR still running.
The Direct To Task Notification API is published here RTOS task notification API functions - the function you are calling (with Generic in its name) is one of the functions used by that API, not something it is intended you call yourself. That said, the way you are calling it doesn’t seem to be wrong. Can you step into the function and see why it is failing? When you stop the code in the debugger after the failure, what is it doing?
More recent Cortex-M ports for other compilers contain a lot of additional configASSERT() calls to trap common configurations in the interrupt priority settings - it is doubtful your version will have those, so I would recommend looking through these pages to see if you can ensure your interrupt priorities are set correctly: RTOS for ARM Cortex-M Additionally, have you done things like ensure stack overflow detection is turned on, etc.? FreeRTOS - Open Source RTOS Kernel for small embedded systems
configASSERT(ucCurrentPriority >= ucMaxSysCallPriority);
An assert failure here tells you the interrupt priorities are not set correctly.
NVIC_SetIntPriority(IVT_INT_USART1, _NVIC_INT_PRIORITY_LVL1);
Priority “1” is actually a very high interrupt priority – too high for making system calls. The link Richard provided explains that lower numbers give higher priorities. In your case, “3” is the maximum priority allowed for system calls (configMAX_SYSCALL_INTERRUPT_PRIORITY being 0x30).
Im not so clear here. This is my case that i have tested.
Case 1
configMAX_SYSCALL_INTERRUPT_PRIORITY being 0x30
NVIC_SetIntPriority(IVT_INT_USART1, _NVIC_INT_PRIORITY_LVL1);
xTaskGenericNotify(xCmd_TaskHandle, NULL, eNoAction, &xHigherPriorityTaskWoken);
Result - Works fine
Case 2
configMAX_SYSCALL_INTERRUPT_PRIORITY being 0x30
NVIC_SetIntPriority(IVT_INT_USART1, _NVIC_INT_PRIORITY_LVL1);
xTaskGenericNotifyFromISR(xCmd_TaskHandle, 0, eNoAction, NULL, &xHigherPriorityTaskWoken);
Result - debugging goes to (configASSERT(ucCurrentPriority >= ucMaxSysCallPriority)
Case 3
configMAX_SYSCALL_INTERRUPT_PRIORITY being 0x30
NVIC_SetIntPriority(IVT_INT_USART1, _NVIC_INT_PRIORITY_LVL5);
xTaskGenericNotify(xCmd_TaskHandle, NULL, eNoAction, &xHigherPriorityTaskWoken);
Result - my uart terminal dont respond to the command received and it will continue printing RTC
What is my solution if i want to use this xTaskGenericNotifyFromISR?
From above, case 3 seems correct.
Okay seems like the problem is FreeRTOS priority. I have created LED task, RTC task & USART task. I set priority LED to 5 & USART to 5 & comment out RTC task create. Works fine. Then i create RTC task with priority 1 & my uart terminal only print rtc value & do not respond to my command. What is suitable way to solve my problem? Thanks in advanced.
Nevermind, my mistake. I forgot to end taskCritical. Thanks for your concern