I’m having a problem of a crash whenever a FromISR function is called in my TWI0_Handler(). I have followed the interrupt priority rule as mentioned here (and tried different numbers) http://www.freertos.org/RTOS-Cortex-M3-M4.html but the problem persists.
So configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY is set to 5 and configLIBRARY_LOWEST_INTERRUPT_PRIORITY is set to 0x0f (as in Demo for SAM3X). And this is how the interrupt is initialized:
Did you remove both printfs? Which version of FreeRTOS are you using? Have you defined configASSERT()? Is taskHandle valid? When you step into the function where does the crash happen?
I’m not familiar with configASSERT, do I have to define it by myself? I found some lines related to it in the FreeRTOS source codes such as this in the FreeRTOSConfig.h: #define configASSERT( x ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); }
and in FreeRTOS.h: #ifndef configASSERT #define configASSERT( x ) #define configASSERT_DEFINED 0 #else #define configASSERT_DEFINED 1 #endif
taskHandle is just a SemaphoreHandle_t defined globally.
The crash happens at xSemaphoreGiveFromISR( testHandle, &xTaskWoken ). This problem also happened with xQueueSendToBackFromISR.
You define it in FreeRTOSConfig.h - it can do what you want as long as
you know it has been called. The normal thing to do is disable
interrupts and sit in a loop, as per your post, so when you break the
debugger you can see it is sat on a configASSERT() statement. There are
more elaborate schemes you can implement - but the simpler the better I
think.
Generally calling printf() in an interrupt is not recommended.
The crash happens at xSemaphoreGiveFromISR( testHandle, &xTaskWoken ).
I think the intention was for you to find out where inside the function
the crash happens. If you place a break point on the line, then step
into the function in the debugger you should be able to see why the
crash happens.
I had confirmed that there was no configASSERT() called and I just found out the problem :).
After looking at the FreeRTOS Demo Application again, I noticed that the Demo sets configTOTAL_HEAP_SIZE as 40960, while I had 8096. After setting it to 40960, the problem disappeared. But I don’t understand why the value was causing the problem.
If you run out of heap then queues, semaphores, event groups, tasks,
etc. cannot be created - and the return value of the function used to
create the object will return pdFAIL. Are you checking the return
values of such functions - or any direct call to pvPortMalloc().
You can also define a malloc failed hook
function to get notification that the heap was exhausted.