I found the ulCriticalNesting init value is 999UL. And I didn’t find the where init the value to 0.
In vPortEnterCritical function, the ulCriticalNesting will be increased and the interrupt will be masked to a setting value.
In vPortExitCritical funciton, the ulCriticalNesting will be decreased. But it will restore the interrupt mask when the ulCriticalNesting value is 0 rather than the value is equal to 999UL.
Can you help to tell me when and where the ulCriticalNesting init to 0 in cortex-r5?
The critical nesting count is part of a Cortex-R task’s context, so it gets set to zero when the first task pops its critical nesting value of its stack. The initial value is zero.
The code you show me is just hold the 0 value to task stack.
But vPortEnterCritical and vPortExitCritical will increase/decrease the ulCriticalNesting rather than the stack value.
And if the ulCriticalNesting is not init to 0 when we invoke vPortExitCritical, the interrupt will not be restored because of ulCriticalNesting value is 99.
If you look at the code that restores the context of a task, it move the value from the context on the stack to the ulCriticalNesting variable (and then copies back to the stack when the context is saved).
So, once we are in the context of a task, and not the code pre-scheduler starting, the value will be set to 0 when we start the task, so when the task has matching enters and exits, the interrupts will be enabled.
It is intentional that pre-scheduler start the interrupt are not enabled, as pre-scheduler interrupts was one of the major sources of bugs, as the ISRs were not written to take that possibility into account, and to do so hurts performance of the ISRs when the system has been started.
