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 );
configMAX_SYSCALL_INTERRUPT_PRIORITY has the default value of 191.
define configMAX_SYSCALL_INTERRUPT_PRIORITY 191.
I also experimented with other values but if the configMAX_SYSCALL_INTERRUPT_PRIORITY 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
hardfaulthandler
The hardfaulthandler is called because xQueueSendToBackFromISR is called.
If i comment this line where xQueueSendToBackFromISR will be called, and the configMAX_SYSCALL_INTERRUPT_PRIORITY stays at value of 15, then no hardfault happen.
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 portASSERT_IF_INTERRUPT_PRIORITY_INVALID() 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 */
portASSERT_IF_INTERRUPT_PRIORITY_INVALID();
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 configMAX_SYSCALL_INTERRUPT_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 configMAX_SYSCALL_INTERRUPT_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 configMAX_SYSCALL_INTERRUPT_PRIORITY has the value of 191.
I don’t understand this.