MCU-PLUS-SDK-AM263X: Which procedure is picked for handling VIM interrupt in MCU+ SDK of AM263x

Hi Frank, 

Thanks for your reply. From the TRM, if the VIC interface is used, the same interrupt signal will not interrupt the running ISR handler, right? (because they have same priority). 

But my customer meets a problem: the PWM interrupt ISR is nested repeatedly (because the ISR's running time is larger than the PWM cycle) and will result in stack overflow, then result in prefetch abort exception. 

Therefore, I recommended them to increase the PWM cycle so that repeated nested-interrupt will not happen. 

But after reading your reply, I am a little confused why the same priority interrupt will be nested. 

Anyway, I will study the VIM deeper by myself. Thanks for your guidance. 

Best Regards, 

Will 

Hi Frank, 

Thanks for your reply.

Frank Livingston said:

Is your customer using FreeRTOS, or NoRTOS?

They are using NORTOS to develop the software. 

Frank Livingston said:

Does they need R5F nested IRQ support for their application? If not, I suggest setting all VIM priorities to the same value.

They set all interrupt's priorities to 4. 

Frank Livingston said:

Do you mean the IRQ stack overflows on the R5F?

May be the general stack is overflowed. 

Frank Livingston said:

I suggest driving GPIOs in the ISRs for different interrupts to clearly observe the behavior causing the issue.

This is a good idea, and I will let them try it. But after I recommend them to increase the PWM cycle, this problem have been solved. So I thought they meet the nested interrupt problem. 

Now, I suppose that the interrupt may not nested, but the user stack still overflows in their original configuration. The reason behind this phenomenon may be the pending PWM interrupt break the process of pop data from stack? 

I will try to test it asap.

Best Regards, 

Will

Hi Will,

Will Gao said:

I will try to test it asap.

Sounds good, I'll wait for the result of your test.

Regards,
Frank

Hi Frank, 

Sorry for my late reply. I have found out the reason why my customer's program will be stack-overflow. The first reason is that they add HwiP_ackIRQ in end of the ISR (they have this habit because of C2000); The second reason is the operating time is larger than the PWM cycle they configured.

Another key point is that they treat the PWM interrupt signal as a pulse. 

In order to re-produce their problem, I write a following Timer project: 

void TIMER_0_callback(void)
{
    HwiP_clearInt(TIMER_0_INT_NUM);   // to simulate isPulse, because the Timer interrupt is not pulse by default. 
    TimerP_clearOverflowInt(TIMER_0_BASE_ADDR) ;
    while( !TimerP_isOverflowed(TIMER_0_BASE_ADDR) ) ;
    timer_cnt = 0xFFFFFFFFu - TimerP_getCount(TIMER_0_BASE_ADDR) ;
    timer_prd = 0xFFFFFFFFu - TimerP_getReloadCount(TIMER_0_BASE_ADDR) ;

//    HwiP_clearInt(TIMER_0_INT_NUM);
    HwiP_ackIRQ(TIMER_0_INT_NUM) ;
}

And the program will get into prefetch abort exception handler: 

As you can see, before getting into prefetch_abort, the prefetched instruction is at 0x67BDA020. Therefore I think it is because the stack is overflowed. 

BR, 

Will 

Hi Will,

My thanks for follow up! Is there any way you could share your entire CCS project as a .zip file?

Regards,
Frank

Hi Frank, 

Please check my attachment below. 

hello_world_am263x-cc_r5fss0-0_nortos_ti-arm-clang.zip

Best Regards, 

Will 

Hi Will,

Thanks for sharing the code!

I'll review your code to better understand the problem and solution. However, my understanding is the issue is resolved, so I'll close the thread for now. I'll re-open the thread and post additional comments depending on what I find in your code.

Regards,
Frank