Does it happen already on the 1st invocation of the ISR ?
Are al handles like xLoadcellTaskEventGroup initialized before the interrupt occurs/is enabled ?
Did you define configASSERT and enabled stack checking during development/debug builds ?
Which FreeRTOS port and version do you use ?
And you also have to initialize xHigherPriorityTaskWoken = pdFALSE.
Yes, it happens on the first invocation of the ISR.
The handler is initialized in main before task is created and scheduler is started.
xLoadcellTaskEventGroup = xEventGroupCreate();
configASSERT is defined as:
#define configASSERT( x ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); }
The version is: FreeRTOS Kernel V10.4.3
It is the version included in the DAVE ide from Infineon.
Have tried to initialize xHigherPriorityTaskWoken to pdFALSE, but that did not help.
Yes, the initialization is not directly related to the crash. But you have to do it to get correct behavior of the flag.
However, your code and the setup looks ok so far.
Are you sure that the task stacks and the main/ISR stack are large enough ?
It helps a lot that it happens systematically. I’d set a breakpoint at the ISR and step through the code to see where it goes wild.
I tried to set a breakpoint at the line “portYIELD_FROM_ISR”, and used the debugger to “Step Over”. But when I do that, the exception does not occur ?
If I just do Run, from the break point the exception occurs. So there is something weird happening.
Indeed that’s weird… Those symptoms could be related to memory/data structure corruption or wrong interrupt priorities. I think the latter should be catched by FreeRTOS ASSERTs. For the 1st potential problem stack overflow checks help. Note on Cortex-M4 it’s not a 100% guarantee.
I guess you check all FreeRTOS API return codes that they were successful where applicable.
Well, the NVIC is a standard peripheral on Cortex-M ARMs. That should be perfectly right.
It’s very strange… is AdcRdyIRQHandler the installed ISR or is it a callback from the real ISR ?
Is it possible that the calling code makes the trouble ?
The code posted is ok so far and is simple enough that it can’t cause any problem. Something else must be wrong
That is because this ISR is ultimately in charge of saving a task context to eventually swith back to, and thus must interrupt only tasks, not ISRs. If it were not lowest pri, it might interrupt other ISRs which would violate that requirement.