Application profiling

Kernel
1

Hi

My application is receiving a CAN message and taking almost 100 ms to respond. This seems a bit too much…
I’m using FreeRTOS 10.3.3 with MPLAB X 5.50 and Harmony 3 on a ATSAMV71-XULT board.

I wonder what are my possibilities in terms of profiling?
Any special plugins available for MPLAB X 5.50?

thanks

2

I think MPLAB X has some FreeRTOS profiling built in - but before that - how are you communicating the arrival of the CAN message to the task that handles it. If the task handling it is Blocked on something like a task notification to wait for the message, and the ISR that signals the receipt of the CAN message sends the notification to the task, then (presuming the task that is unblocked has a high priority) the interrupt should return directly to the task that consumes the CAN messages. If you architect like that it should take sub-millisecond time between message arrival and message processing. This page shows the design pattern: https://www.freertos.org/RTOS_Task_Notification_As_Counting_Semaphore.html

3

Yes the interrupt routine receives a message and it signals through a semaphore to the receiving task which in turn processes the message.
I have increased the priority by 1 of the receiving task but still the same behaviour. Around 100 ms since reception until sending the response…



	if ( xTaskCreate ( (TaskFunction_t)socketcan_rx_thread, "socketcan_rx_thread",
                       TASK_STACK_SIZE, (void*)&ctx, TASK_PRIORITY+1, (TaskHandle_t * const) socketcan_rx_thread_TH ) != pdPASS )



static void CAN1_rx_callback (uintptr_t contextHandle)
{
	if ( Rx_mutex != NULL )
	{
        uint16_t timestamp;
        MCAN_MSG_RX_FRAME_ATTRIBUTE msgFrameAttr = MCAN_MSG_RX_DATA_FRAME;
		if ( !msgRx_valid )
		{
			BaseType_t xHigherPriorityTaskWoken;

            {
                bool result;
                result = MCAN1_MessageReceive ( &messageID, &messageLength, message, &timestamp, MCAN_MSG_ATTR_RX_FIFO0, &msgFrameAttr );
                if ( result )
                {
        			msgRx_valid = true;
                    xSemaphoreGiveFromISR ( Rx_mutex,&xHigherPriorityTaskWoken );
                    portYIELD_FROM_ISR ( xHigherPriorityTaskWoken );
                }
            }
		}
		else
		{
            MCAN1_MessageReceive ( &messageID, &messageLength, message, &timestamp, MCAN_MSG_ATTR_RX_FIFO0, &msgFrameAttr );
            msgRx_discarded++;
		}
	}
}

static void * socketcan_rx_thread(void * arg)
{
	can_context_t * ctx = arg;

	while (1)
	{
        uint16_t timestamp;
        MCAN_MSG_RX_FRAME_ATTRIBUTE msgFrameAttr = MCAN_MSG_RX_DATA_FRAME;

        // First call to MCAN1_MessageReceive is just to enable Receive Interrupt!!!
        MCAN1_MessageReceive ( &messageID, &messageLength, message, &timestamp, MCAN_MSG_ATTR_RX_FIFO0, &msgFrameAttr );

		xSemaphoreTake ( Rx_mutex, portMAX_DELAY );

        /* Call RX callbacsp_can_rx_frameck */
        csp_can_rx(&ctx->iface, messageID, message, messageLength, NULL);

        msgRx_valid = false;
	}
	return NULL;
}

I’ll investigate the profiling capabilities of MPLAB X.

4

you should consider tracealyzer or a compatible tool, it’s perfectly tailored to your cause.

5

Minor point - not the cause of your observation - but xHigherPriorityTaskWoken should be initialised to 0 (pdFALSE). It will then get set to pdTRUE only if a context switch is required, which can save you some cycles.

6

thanks. At the moment I think the problem is not related with FreeRTOS or the CAN/UART driver. Investigating…