I am wanting to set the priority of a SPORT DMA interrupt to be the highest in the SHARC+ core of an SC572. By default I believe the SEC sets interrupt priorities to 0 (all at the highest). When I try setting a SPORT DMA interrupt to priority 1 (yes, lower, but I wanted to try it) the scheduler will not start. There is a fatal_error. I've tried changing the priority of other interrupts, including that of the RTOS scheduler, and I get the same problem. Am I missing some fundamental step here? How can I tweak interrupt prioritires on the SHARC+ running FreeRTOS.
edit: If I disable the interrupt whose priority I changed, the program will run. So it doesn't appear to be some kind of check happening that is failing. This makes me suspect registers being clobbered or something like that. For the SPORT the ISR callback is registered through `adi_sport_RegisterCallback`.
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.
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
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.
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
