[PIC32] using ISR before the scheduler start

Hello!
I’m working on an application that use two timers.
The firts timer is set to priority 7 while the second is set to priority 6.
i need the isr to be raised before the start of the the os scheduler so I initialize the interrupt before declaring any tasks.
I encounter a strange behavior changing the value of configMAX_SYSCALL_INTERRUPT_PRIORITY.
Setting it on 0x7 i get both the isr to work correctly “after” the scheduler start.
If i set it on a value lower than 6 i get them to work correctly “before” the scheduler start.
What i’m doing wrong?
Thanks in advance for any help.

[PIC32] using ISR before the scheduler start

I found that a possibly cause of my problem is the freertos interrupt masking.
In fact if i set configMAX_SYSCALL_INTERRUPT_PRIORITY = 7 it mask my two timer whose priorities are 7 and 6.
So there is a way to unmask interrupts before the scheduler starts?
I need to do something like that:
int main(void)
{
  unmaskinterrupts();
  // my function that wait for timers interrupts raising…
  maskinterrupts();
 
  createtasks();   vTaskStartScheduler();
} Thanks again!
 

[PIC32] using ISR before the scheduler start

In the general case, it is not good to allow interrupts to execute before the kernel is started.  That is because there is potential for a crash if the ISR attempts to call a FreeRTOS API function before the scheduler has started – or even worse, attempts a context switch (the latter case will definitely cause a crash).  Therefore, FreeRTOS API functions will return with interrupts masked to the defined max syscall priority when they are called before the scheduler is started.  For example, calling xTaskCreate() before the scheduler is started will result in interrupts being masked. You can manually unmask the interrupt by calling taskENABLE_INTERRUPTS(), but interrupts will be masked again if another FreeRTOS API function is called before vTaskStartScheduler(). Regards.

[PIC32] using ISR before the scheduler start

Thanks a lot!
It works perfectly.