PIC32 Core Timer and xTimerCreate()

FreeRTOS disables interrupts of priority up to configMAX_SYSCALL_INTERRUPT_PRIORITY. The OP said that the timer interrupt’s priority is higher than configMAX_SYSCALL_INTERRUPT_PRIORITY, so either the timer interrupt’s priority is changed elsewhere or interrupts are disabled elsewhere.

@aggarg There is a sub-routine in xTimerCreate, enterCRITICALSECTION is called before entering into this sub-routine, this enterCRITICALSECTION disables all interrupts. and before leaving the sub-routine exitCRITICALSECTION is called which is supposed to enable all the interrupts. But the catch is in exitCRITICALSECTION function a check has been implemented that if and only the scheduler is running then it will enable the interrupts otherwise the check will turn out to be false leaving the interrupts disabled.

That does not seem to be from the official FreeRTOS.

static void prvCheckForValidListAndQueue( void )
{
    /* Check that the list from which active timers are referenced, and the
     * queue used to communicate with the timer service, have been
     * initialised. */
    taskENTER_CRITICAL();
    {
        if( xTimerQueue == NULL )
        {
            vListInitialise( &xActiveTimerList1 );
            vListInitialise( &xActiveTimerList2 );
            pxCurrentTimerList = &xActiveTimerList1;
            pxOverflowTimerList = &xActiveTimerList2;

            #if ( configSUPPORT_STATIC_ALLOCATION == 1 )
                {
                    /* The timer queue is allocated statically in case
                     * configSUPPORT_DYNAMIC_ALLOCATION is 0. */
                    PRIVILEGED_DATA static StaticQueue_t xStaticTimerQueue;                                                                          /*lint !e956 Ok to declare in this manner to prevent additional conditional compilation guards in other locations. */
                    PRIVILEGED_DATA static uint8_t ucStaticTimerQueueStorage[ ( size_t ) configTIMER_QUEUE_LENGTH * sizeof( DaemonTaskMessage_t ) ]; /*lint !e956 Ok to declare in this manner to prevent additional conditional compilation guards in other locations. */

                    xTimerQueue = xQueueCreateStatic( ( UBaseType_t ) configTIMER_QUEUE_LENGTH, ( UBaseType_t ) sizeof( DaemonTaskMessage_t ), &( ucStaticTimerQueueStorage[ 0 ] ), &xStaticTimerQueue );
                }
            #else
                {
                    xTimerQueue = xQueueCreate( ( UBaseType_t ) configTIMER_QUEUE_LENGTH, sizeof( DaemonTaskMessage_t ) );
                }
            #endif /* if ( configSUPPORT_STATIC_ALLOCATION == 1 ) */

            #if ( configQUEUE_REGISTRY_SIZE > 0 )
                {
                    if( xTimerQueue != NULL )
                    {
                        vQueueAddToRegistry( xTimerQueue, "TmrQ" );
                    }
                    else
                    {
                        mtCOVERAGE_TEST_MARKER();
                    }
                }
            #endif /* configQUEUE_REGISTRY_SIZE */
        }
        else
        {
            mtCOVERAGE_TEST_MARKER();
        }
    }
    taskEXIT_CRITICAL();
}

this is the sub-routine I was talking about, I am sorry for not using the exact naming. It is taskENTER_CRITICAL() and taskEXIT_CRITICAL()

This is how taskENTER_CRITICAL works -

Therefore, the timer interrupt will only be masked if its priority is less than or equal to configMAX_SYSCALL_INTERRUPT_PRIORITY? Can you query its priority before calling xTimerCreate?

1 Like

Yes, you are correct.
@aggarg please accept my apology. I remember I had set the priority of Core Timer 7 earlier, now I have checked again after reading your message and I don’t how it is set at 1…

@aggarg I am sorry for providing wrong information earlier…

No worries. Does your problem go away after changing the interrupt priority to 7?

I didn’t try it yet, I have just enabled the interrupt after the xTimerCreate, it is working for now. However I need to set the priority at 7, will do it and inform you about the result.