Changing interrupt priority using adi_sec_SetPriority causes a fatal_error when starting FreeRTOS

Hi,

Thank you for your inquiry.

From your query, we understood that you have integrated SPORT application in an RTOS environment and it works when the default priority has been set for SPORT and facing an issue while you are changing the priority of SPORT interrupt.

For Ex, from Table 6-5: ADSP-SC57x Combined SEC and GIC Interrupt List from HRM, SPORT0 Channel A DMA interrupt ID is 60 and you are changing it's priority to CGU0 Event(i.e high priority event). While trying like this you are getting a fatal error. Please clarify whether our understanding is correct here.

Waiting for your reply.

Best Regards,
Santhakumari.V

Hello,

Yes I've integrated SPORT aquisition in an RTOS environment on the SHARC+ core of an SC572. By default priorities in the SEC look to be 0. The SPORT interrupt is configured to interrupt the SHARC+ core. Changing priority with the below code (it's SPORT B DMA that we use for the ISR) causes the fatal error, but only when the SPORT is enabled (I presume then that it's occurring when the interrupt fires).

adi_sec_SetPriority(62, 1);

Hi,

Thanks for confirming our understanding.

As you mentioned, all SEC interrupts are configured with the same default priority value of 0.

From your previous response, we understand that the SPORT DMA interrupt priority is being changed after enabling the SPORT. If our understanding is correct, could you please let us know the reason for changing the SPORT DMA interrupt priority after enabling the SPORT?

In general, it is recommended to configure the interrupt priority before enabling the peripheral and allowing interrupts to occur. This ensures that all interrupts generated by the peripheral are serviced using the intended priority from the start of operation.

To reproduce the reported behavior, we developed a test application in which data is continuously transmitted from SPORT0B to SPORT0A. The SPORT peripherals are initialized in vApplicationDaemonTaskStartupHook(), and after enabling the SPORTs, we changed the priority of the corresponding SPORT interrupts from 0 to 1.
On our ADSP-SC573 EZ-KIT setup, the application continues to run correctly and we have not been able to reproduce the reported fatal error. 

Please find the attached code and refer to the image below for reference.

SC573_SPORT_RTOS.zip

Could you please check the attached code and let us know if any additional steps are required to reproduce the issue? If possible please share us a simple project which replicate the issue on Ezkit. This will help us reproduce the issue and assist you further.

Best Regards,
Santha kumari.V

Thanks for the quick response.

I have tried changing the priority before enabling the sport - setting priority after calling adi_sec_init and also later. Neither work. I'll have a look at the example and test it on my ezkit.

I am able to run the example and it's ok... but to reproduce the issue we're seeing we really need to throw a party!

With the following modifications to the provided example, I can reproduce a fatal_error.

1. Add two tasks. Both loop freely incrementing a counter. No yielding.
2. Enable time slicing - my goal is to have the scheduler interrupt fire often.
3. Increase the tick rate to 10,000.

With these changes I only run for a little while before having a fatal_error. However, with these changes and setting the SPORT ISR priority back to 0, I ran for several minutes without any issues.

TaskHandle_t xCnt1TaskHandle;
TaskHandle_t xCnt2TaskHandle;

void CounterTask(void *pvParameters)
{
	uint32_t i = 0;
	while (1)
	{
		i++;
	}
}

	xTaskCreate(CounterTask, "Cnt1 Task",1000, NULL,5,&xCnt1TaskHandle);
	xTaskCreate(CounterTask, "Cnt1 Task",1000, NULL,5,&xCnt2TaskHandle);

Santhakumari are there any updates on this, were you able to reproduce what I saw with the example?

Hi,

We are able to reproduce the observation. Is there any specific reason for having this high tick rate 10,000?(Tick interrupt generated at an interval of every 100microseconds)

This obviously increases CPU overhead, context switching overload and interrupt pressures.

Waiting for your reply.

Best Regards,
Santhakumari.V

I think I will ultimately lower the tick rate for those reasons, at the time I felt it was a good fit for our system. This tick rate is working when all interrupts are at 0 priority. If I change the tick interrupt or the SPORT interrupt to another priority, the fatal_error occurs - this suggests a problem with interrupt nesting, even with a lower tick rate I'd think the problem is still out there but less likely to occur.