Hello. I am writing a function, which is called both from task as well as from an isr. My FreeRTOS Version is 8.2.0. ~~~~ xHigherPriorityTaskWoken == pdFALSE;
if(TRUE == Task)
{
xQueueSendToBack(SendQueue,(uint32t*) &sendaStruct, 0);
}
else
{
Ticks = xTaskGetTickCountFromISR();
xQueueSendToBackFromISR(SendQueue, (uint32t*) &sendaStruct, &xHigherPriorityTaskWoken)
}
~~~~
If I call the xTaskGetTickCountFromISR(); function, then the µController jumps to the vAssertCalled() function.
If I comment the line with xTaskGetTickCountFromISR(), the µC jumps to vAssertCalled(), when calling the xQueueSendToBackFromISR() function.
The callstack shows me, that the µC jumps to
vPortValidateInterruptPriority() and call the macro: configASSERT( ucCurrentPriority >= ucMaxSysCallPriority );
configMAXSYSCALLINTERRUPTPRIORITY has the default value of 191.
define configMAXSYSCALLINTERRUPTPRIORITY 191.
I also experimented with other values but if the configMAXSYSCALLINTERRUPTPRIORITY value is smaller than 16 (15 is my lowest ISR priority) then the HardFault Handler is called.
When the HardFault happen, the call stack shows me this:
xPortStartScheduler
prvPortStartFirstTask
I hope someone can help me.
Best Regards
If I call the xTaskGetTickCountFromISR(); function, then the µController jumps to the vAssertCalled() function.
I have just looked at the xTaskGetTickCountFrom() function and the only assert I see is this one:
~~~~ /* RTOS ports that support interrupt nesting have the concept of a maximum system call (or maximum API call) interrupt priority. Interrupts that are above the maximum system call priority are kept permanently enabled, even when the RTOS kernel is in a critical section, but cannot make any calls to FreeRTOS API functions. If configASSERT() is defined in FreeRTOSConfig.h then portASSERTIFINTERRUPTPRIORITYINVALID() will result in an assertion failure if a FreeRTOS API function is called from an interrupt that has been assigned a priority above the configured maximum system call priority. Only FreeRTOS functions that end in FromISR can be called from interrupts that have been assigned a priority at or (logically) below the maximum system call interrupt priority. FreeRTOS maintains a separate interrupt safe API to ensure interrupt entry is as fast and as simple as possible. More information (albeit Cortex-M specific) is provided on the following link: http://www.freertos.org/RTOS-Cortex-M3-M4.html */ portASSERTIFINTERRUPTPRIORITYINVALID(); ~~~~
I'm not sure I can really add much more than the information provided in the comment at the assert point, or the more detailed information on the link provided in the comment. The obvious question then is, not have you tinkered with the configMAXSYSCALLINTERRUPT_PRIORITY setting, but have you set the priority of the interrupt? Please read the link.
Hello. Thank you for your answer. I found the bug. The explanation is: I activated the configAssert macro in freeRTOS. After this I got a failure while colling the xFromISR functions. The problem was, that the configMAXSYSCALLINTERRUPT_PRIORITY was at the default value of 191. I changed the value from 191 to 15, while I worte my post yesterday (I overseen this define before). After I changed the value to 15 xTaskGetTickCountFrom didn't cause any failure. But xQueueSendToBackFromISR crashes, as I wrote. While I was debug my assert failure, I tried to send an other struct. I removed this other struct and tried to send my origin struct, but I forgot to remove the other struct to my origin struct in the function call of xQueueSendToBackFromISR. So I set my origin struct and now the calling of xQueueSendToBackFromISR works.
Can you explain me, why configMAXSYSCALLINTERRUPT_PRIORITY has the value of 191. I don't understand this.
Thank you very much.
did you read the link in the code comments in the last post?