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.

TMS320F280045: Incorrect ISR jump address

Part Number: TMS320F280045

For a few weeks now, we noticed a very strange misbehavior with individual newer DSPs. The errors have only been occurring in recent weeks although we have not made any changes to software nor hardware.

What we noticed so far, is that the allegedly bad DSP show different values for intVect and thisVect when entering the default ISR (see sample code) . We think that the DSP jumps to the wrong ISR. What could lead to this strange behavior?

interrupt void DEFAULT_ISR(void)  // dummy ISR
{
   volatile int32 intX, intT;
   volatile uint32 intVect, thisVect;

   /* SEE PieVect.h */
   intX = (uint32)PieCtrlRegs.PIECTRL.all;
   intVect = *(uint32*)intX;                //This is the InteruptServiseRroutine he should have jumped
   
   thisVect = (uint32)DEFAULT_ISR;          //This is the InteruptServiseRroutine he actualy jumped

   //some code

   //Write values in not initialised code sector
   bootInfo.pieIsrVector = intVect;
   bootInfo.thisIsrVector = thisVect;
   
   //some code
   
   for(;;); //Here reset of system because of WatchDog time out
}
 

  • Hi Christian,

    Thanks for your question. Does the code happen to have any interrupt nesting in it (it looks like it may from the PIECTRL read on line 7)? There is a caution that must be had when nesting to avoid spurious interrupts, as outlined in the device errata:

    There is also this caution:

    For this one, essentially the order of operations when doing PIEACK or PIEIER setting/clearing must be carefully considered.

    Details on the precautions of nesting are also in this guide here:

    https://software-dl.ti.com/C2000/docs/c28x_interrupt_nesting/html/index.html

    From your description, assuming nesting is getting enabled in the actual code (there's no EINT here so I'm not sure if it is), then it's possible that another interrupt is triggering between lines 8 and 10 (between the two reads) and potentially that is the other ISR you are reading.

    This can be a very intermittent issue, so that could be why you only see it occasionally on one device. But, if it is happening FREQUENTLY on that one device, then it may not be a nesting issue.

    Regards,

    Vince