• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 925 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Reason for Spurious F28069 RTOSINT_ISR?

Mark Walsh1
Prodigy 180 points

Using Code Composer Studio Version: 5.4.0.00091, we ported our old LF2407A code to the F28069, and we have our power conversion working at very low power.  After writing the code to support the trip zones, in making a very minor change to some unrelated code that does some simple book-keeping, our CPU now hits an ESTOP0 in the F2806x_DefaultIsr.c function, RTOSINT_ISR(void).  We do not use an RTOS, so we do not intentionally set its bit (bit 15) in the IER.  While stuck in the RTOSINT_ISR, the IER is 0x2007 (note that bit 15 is not set), and the IFR is 0x0000.  For what it might be worth, DBGIER (which our code does not reference) is 0x0040.  Searching our code for lines containing "IER" yields the following:

IER = 0x0000;
IER |= M_INT1;
IER |= M_INT13;
IER |= M_INT14;
PieCtrlRegs.PIEIER1.bit.INTx7 = 1;
PieCtrlRegs.PIEIER1.bit.INTx1 = 1;
IER |= M_INT3;
PieCtrlRegs.PIEIER3.bit.INTx1 = 1;
IER |= M_INT2;
PieCtrlRegs.PIEIER2.bit.INTx1 = 1;
PieCtrlRegs.PIEIER2.bit.INTx2 = 1;
PieCtrlRegs.PIEIER2.bit.INTx3 = 1;
PieCtrlRegs.PIEIER2.bit.INTx4 = 1;
PieCtrlRegs.PIEIER2.bit.INTx5 = 1;
PieCtrlRegs.PIEIER2.bit.INTx6 = 1;

What could be causing this interrupt to occur, and what can be done to keep it from occurring?

Thanks -- Mark

  • 0
    TI__Guru* 93800 points

    Mark,

    A couple of thoughts - it could be that yes you took an interrupt.   But since the interrupt is never enabled by your code it could also be that the code went into the weeds and you just happened to halt at the ESTOP in the interrupt. 

    Mark Walsh1 said:
    We do not use an RTOS, so we do not intentionally set its bit (bit 15) in the IER.  While stuck in the RTOSINT_ISR, the IER is 0x2007 (note that bit 15 is not set), and the IFR is 0x0000.

    When an interrupt is entered the CPU IER and IFR flags are cleared by the hardware.  What you could do is look at the stack to see if it was set before the interrupt was taken.

    You could examine the stack when you land in the ISR to see if (a) the stack didn't overflow (b) it makes any sense (ie the information "looks like" a valid interrupt context save, the PC was / or was not at a valid address when this occurred, and if it was a valid save what the contents of IER were).  

    A context save is described here: http://processors.wiki.ti.com/index.php/C28x_Context_Save_and_Restore

    One quick and dirty way to check how much stack is being used (and thus if it overflowed) is to fill the area with a value with CCS before running the application. 

    -Lori

  • 0 in reply to Lori Heustess
    Prodigy 180 points

    Lori, I am sorry to take so long to get back to you!

    To make a long story short, the problem was caused by a programming error that caused the stack to run into the heap.  I would have liked to have "stepped out" of the problem ISR, but Code Composer Studio would not let that happen.  I had commented out the "for loop" because I couldn't figure out how to set the PC to the next line of code (the old Code Composer had a "set PC to here" selection).

    Does Code Composer Studio have a means of showing the stack tree?  I tried looking for some such tool, but to no avail.  All that I could do was to fill the stack with a pattern (0x5a5a) and find out where it started to get wiped out, and that eventually led me to find the problem.

    Thanks -- Mark