• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 981 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.

Troubleshooting source of unplugged interrupt #96

Karthik Rao1
Prodigy 70 points

Other Parts Discussed in Thread: TMS320F28335, SYSBIOS

Hi,

 Here is the software versions of the tools I'm using,

    CCS : Version: 5.3.0.00090
    XDC tools : 3.24.5.48
    Compiler version TI 6.1.0
    SYS/BIOS : 6.34.2.18
    Device :TMS320F28335

I have enabled a loop back test on interrupt based SCI B. I have configured Interrupts for both SCI B and SCI C,whereas SCI A interrupt is completely disabled. After the successful transmission and reception of data on SCI B port,I'm noticing the following information on console and the device will come to hang state.

"ti.sysbios.family.c28.Hwi: line 953: E_unpluggedInterrupt: Unplugged interrupt flagged: intr# 96
xdc.runtime.Error.raise: terminating execution"

I can note that #96 is related to SCI A.I'm unable to notice the relation on which occasion this is getting triggered even though I have completely disabled the SCI A interrupt(and also the GPIOs are not configured as SCIAtxd/SCIArxd)

Also,If I run the same loop back test on SCI C(without SCI B),it runs successfully without the above message/hanging.

Please help me out in solving this issue.Let me know if you need any further details.

Thanks,

Karthik Rao.

  • 0
    TI__Mastermind 32475 points

    Unfortunately this is a software forum.  I can confirm that #96 is SCI-A source interrupt.  The error being raised means two things:

    1.  Interrupt #96 is being raised

    2.  The code executing is somehow executing Interrupt #96....could be via a bad branch.

    You need to determine whether its just a bad branch or if its a bogus interrupt being generated.

    Judah

  • 0 in reply to judahvang
    Prodigy 70 points

    Thank you for your information.

    well, I have not configured SCI-A interrupt in the configuration page of my project.I cross verified again in my project that SCI A interrupt is not enabled anywhere.

    In order to resolve this, I did some work around.

    Here is the sample SCI-B transmit interrupt code,in which I could see the error message.

    void SciBTxFifoIsr(void)
    {

    Transmit the Bytes into ScibRegs.SCITXBUF;

    ScibRegs.SCIFFTX.bit.TXFFINTCLR = 1;

    /* Acknowledge Group 9 INT */
      PieCtrlRegs.PIEACK.all|= PIEACK_GROUP9;

    /*Disable SCIB TX INT*/

    PieCtrlRegs.PIEIER9.bit.INTx4 = 0;

    }

    The work around I did was,

    void SciBTxFifoIsr(void)
    {

    Transmit the Bytes into ScibRegs.SCITXBUF;

    /*Disable SCIB TX INT*/

    PieCtrlRegs.PIEIER9.bit.INTx4 = 0;

    ScibRegs.SCIFFTX.bit.TXFFINTCLR = 1;

    /* Acknowledge Group 9 INT */
      PieCtrlRegs.PIEACK.all|= PIEACK_GROUP9;

    }

    I just shifted disable interrupt before clearing FIFO interrupt.After the above work around/modification, I never saw the error message again.I can still reproduce it with the older modification.

    My question is,Do you see any reason on what made this to resolve?

    Is there any timing issue which can trigger the #96 interrupt?

    Karthik.

  • 0 in reply to Karthik Rao1
    TI__Mastermind 32475 points

    From your post, what I'm getting is that Interrupt #96 is getting triggered.  If this is truly the case, I think this post needs to be moved to a hardware specific forum so that someone who understands the hardware can comment on why this interrupt is being triggered.

    I don't know the specifics of this hardware so I don't know why your workaround would resolve the problem.

    I am not aware of any timing register that can trigger #96.

    Judah