DSP interrupt&FreeRTOS

I would like to ask that my project currently uses the RTOS port linked below, and the chip used is DSP28P65 series. I handle the rest interrupts by semaphore, but AD interrupts are still executed in the ISR function, and there is feeding the dog operation in AD. The current situation is that timeout reset occurs. Do I feel that every time the RTOS blocks all interrupts, my AD cannot execute in time, so it causes timeout reset? How to solve this problem? Thank you!

https-github.com-FreeRTOS-FreeRTOS-Kernel-Community-Supported-Ports-tree-main-CCS-C2000_C28x

Hi Will,

FreeRTOS kernel doesn’t perform non-deterministic operations inside the critical section. After leaving the critical section, interrupts are enabled again, and the AD interrupt should be able to run. Can you help by sharing your code here? Then we can better understand the situation. It would be even better if you can indicate the code running by the CPU when the watchdog reset timeout occurs.

Thanks for your reply. Due to confidentiality reasons, I have probably attached the interrupt framework and made an interrupt nesting in AD interrupt to ensure that my AD interrupt will not be interrupted, because AD interrupt executes very important content, and the interrupt service function of other interrupts is only used to release semaphore. The specific content of each interrupt execution is made into the form of tasks. Now the situation is that the code will have a timeout reset phenomenon after running for a period of time, if I put the rest of the interrupt processing content is also executed in the ISR function, and the interrupt nesting will not appear timeout reset phenomenon, so I think it is the reason for the RTOS system.

__interrupt void adc_isr(void)
{
    
    volatile uint16_t tempPIEIER = HWREGH(PIECTRL_BASE + PIE_O_IER1);
    IER |= M_INT1;
    IER &= MINT1;
    HWREGH(PIECTRL_BASE + PIE_O_IER1) &= MG1_1;
    Interrupt_clearACKGroup(0xFFFFU);
    __asm("  NOP");
    EINT;
    .....
    code;
    serviceWatchdog;
    .....
    DINT;
    HWREGH(PIECTRL_BASE + PIE_O_IER1) = tempPIEIER;
}

__interrupt void ECan_ISR0(void)
{

    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    xSemaphoreGiveFromISR( binarySem2Handle, &xHigherPriorityTaskWoken );
    Interrupt_clearACKGroup(INTERRUPT_ACK_GROUP9);
    portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
}
void ECanA_isr0_Task( void * pvParameters )
{
   for(;;)
   {
       if(xSemaphoreTake( binarySem2Handle, portMAX_DELAY ) == pdTRUE)
      {   
      	code ;
      }   
   }
}


__interrupt void Sci_RxIsr(void)
{
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    xSemaphoreGiveFromISR( binarySem4Handle, &xHigherPriorityTaskWoken );
    xTaskResumeFromISR(Scia_Rx_isr_TaskHandle);
    sClearSciIntFlag();
    Interrupt_clearACKGroup(INTERRUPT_ACK_GROUP9);
    portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
}

void Scia_Rx_isr_Task( void * pvParameters )
{
    for(;;)
    {
        if(xSemaphoreTake( binarySem4Handle, portMAX_DELAY ) == pdTRUE)
        {          
					code;
        }
    }
}

what are the relative prorities of your isrs?

If the code of your adc interrupt that services the watchdog does not interact with FreeRTOS, you can set its priority to above max_syscall. If you then still experience the problem, it can not be OS related.

In any case I would recommend using tracealyzer which is exactly the kind of tool for those kinds of problems.

A good way to implement an ISR is to keep minimal processing within the ISR and even smaller part in the critical section.
If there is a bigger processing to be done, that can be done in the bottom-half, which has a higher priority than the other threads but lower priority than ISR. The main ISR will do the minimal processing and start the bottom half.

Hello,
Thanks for asking this, I am also facing same issue.