TMS320F280049C: Could stack be overflowed if not EINT

Johnny Chen

Part Number: TMS320F280049C

Hi Champ,

I am asking for my customer.

They have initialized the peripheral stage and PIE stage (Initialize PIE vector table, re-mapped to ISR functions) and do the Interrupt_enable(INT_x) to propagate the interrupt request correctly, while they did it on purpose without doing the enable the global interrupt (EINT) after PIE initialization, and hold it for a while for some background stuffs, then finally enable the global interrupt (EINT).

The pseudo code is as follows,

void init_interrupt (void)
{
    EALLOW;
    PieVectTable.SCIA_RX_INT = &Uart_Rx_Isr;
    ..... // other peripherals' PIE re-mapping to ISR functions
    ..... // other peripherals' PIE re-mapping to ISR functions
    EDIS;
    
    PieCtrlRegs.PIEIER9.bit.INTx1 = 1;
    ..... // other peripherals' PIE IER
    ..... // other peripherals' PIE IER
    
    IER |= M_INT9 | ... |... ;
    
    //EINT;
    //ERTM;
}

In this period of time w/o doing the EINT yet, there have been peripherals interrupt requests pending in the CPU stage one after another. If user doesn't enable the global interrupt (EINT), could stack be overflowed before they enable EINT and start to execute ISRs ?

Thanks and regards,

Johnny

over 1 year ago

0 Hareesh Janakiraman over 1 year ago

TI__Guru* 95315 points

Johnny,

The stack comes into play (i) when interrupts are serviced and (ii) during a Call (when the return address is pushed to the stack). The number of registers pushed to the stack is a lot more when an interrupt is serviced as opposed to a Call, so I don’t see how the stack could overflow when the interrupts are not serviced. Please refer to www.ti.com/lit/SPRA820 for helpful tips.

0 Johnny Chen over 1 year ago in reply to Hareesh Janakiraman

TI__Expert 5090 points

Hi Hareesh,

Thanks for the reply.

Let me describe more on customer's situation and please chime in for any thought.

Cause the user did the interrupt request as pseudo code shown above in the main(), didn't enable the INTM following until did it (EINT) in a statement(#ifelse) in while loop. While before the code running to while loop(EINT), there are actually peripherals' ISR requesting, and propagate to CPU stage and awaiting EINT.

However, customer found out that the ISR (RX_ISR) which should definitely 100% happen (another device always transmit message to F280049C), has a rare chance that the RX_ISR isn't generated after EINT after cold reset, they are doing such test to ensure the any ISRs should be generated all the time. So, we are figuring out is there a possibility that before enabling EINT, the stack has been overflowed, causing that a 100% showing ISR might have a chance to miss it.

Any thought on why a 100% suppose to be happened ISR not generating ISR all the time after repeatly cold reset ?

Thanks and regards,

Johnny

+1 Hareesh Janakiraman over 1 year ago in reply to Johnny Chen

TI__Guru* 95315 points

Johnny Chen said:
Cause the user did the interrupt request as pseudo code shown above in the main(), didn't enable the INTM following until did it (EINT) in a statement(#ifelse) in while loop. While before the code running to while loop(EINT), there are actually peripherals' ISR requesting, and propagate to CPU stage and awaiting EINT.

Sorry, I don't understand what you are trying to say here.

Johnny Chen said:
However, customer found out that the ISR (RX_ISR) which should definitely 100% happen (another device always transmit message to F280049C), has a rare chance that the RX_ISR isn't generated after EINT after cold reset, they are doing such test to ensure the any ISRs should be generated all the time. So, we are figuring out is there a possibility that before enabling EINT, the stack has been overflowed, causing that a 100% showing ISR might have a chance to miss it.

The stack has no bearing in whether an interrupt is serviced. True, registers to be saved are pushed to the stack when servicing of an interrupt begins. But, whether or not an interrupt is serviced is independent of the condition of the stack. If the stack has overflown (corrupted), it will impact the restoration of the device status prior to the servicing of the interrupt. Not the servicing of the interrupt itself.

Johnny Chen said:
Any thought on why a 100% suppose to be happened ISR not generating ISR all the time after repeatly cold reset ?

Customer should trace all the enable bits (i) at the peripheral level (ii) at the PIE level and (iii) at the CPU level.

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F280049C: Could stack be overflowed if not EINT