instaspin and adding a interrupt to the PIE controller

Hi Evs,

What are the contents of IER once you are done with the setup ?

Thanks

Noah

 I removed all the other code. So I only running in an endless loop. No data is send/received from/to SCI-B. pin signals are 3.3V (stable). Fifo is empty (ScibRegs.SCIFFTX.bit.TXFFST = 0 and ScibRegs.SCIFFTX.bit.TXFFIL = 2)

 This is my interrupt code:

 __interrupt void scibTxFifoIsr(void)
{
ScibRegs.SCITXBUF=Ringbuffer_Pop (&gTXbuf);
    ScibRegs.SCIFFTX.bit.TXFFINTCLR=1;  // Clear SCI Interrupt flag
    PieCtrlRegs.PIEACK.all|=0x100;      // Issue Group 9, PIE ACK
}

When I debug the code: Afer PIEACK the function is called again. So I think that ScibRegs.SCIFFTX.bit.TXFFINTCLR is not clearing the ScibRegs.SCIFFTX.bit.TXFFINT bit. I see that also in my debug window.

 SCIFFTX is not protected by EALLOW.  So what is the problem?

edit: 

This works fine: 

__interrupt void scibRxFifoIsr(void)
{ char x;

    x=ScibRegs.SCIRXBUF.all;
    ScibRegs.SCITXBUF=x;

    ScibRegs.SCIFFRX.bit.RXFFOVRCLR=1;   // Clear Overflow flag
    ScibRegs.SCIFFRX.bit.RXFFINTCLR=1;   // Clear Interrupt flag
    PieCtrlRegs.PIEACK.all|=0x100;       // Issue Group 9, PIE ack

}

Hi Evs,

I am not sure I followed your question. In the original email you see issue with un-intended interrupts being disabled/ enabled. We need to see the contents of IER if some other code is changing the values.

When you acknowledge an interrupt , you are indirectly enabling the module to generate an interrupt again. An interrupt occurring after clearing the PIEACK register is not an issue.

If the interrupt is happening too often, you need to adjust your system to sync appropriately.

Thanks

Noah

Noah,

The IER is 0x2300. And I really like to know how to "system to sync appropriately" because I think the interrupt controller is very limited and that is a part of the problem.  Especially  for a power electronics controller.

I have the f28069M controller.

 I debug it a bit further and I think there is a problem.

 The TX interrupt is generated when the controller is ready to sent another character. Which is nice, exact when you have nothing to send or that you're baud rate is so high that that there is no wait. Then the interrupt is direct generated again.

 This can starve other interrupts and brings my system down. Everything with a lower priority than group 9 will never be serviced including my main code.

example:

__interrupt void scibTxFifoIsr(void)
{
    ScibRegs.SCIFFTX.bit.TXFFINTCLR=1;  // Clear SCI Interrupt flag
    PieCtrlRegs.PIEACK.all|=0x100;      // Issue Group 9, PIE ACK
}

Ok,  to solve this: When I send a string I start the TX interrupt and when  finished, I stop the TX interrupt.

I changed the code to this. When My transmit buffer is empty I disable the interrupt.

__interrupt void scibTxFifoIsr(void)
{

   ScibRegs.SCICTL2.bit.TXINTENA =0;     // Disable TX interrupt.
    ScibRegs.SCIFFTX.bit.TXFFINTCLR=1;  // Clear SCI Interrupt flag
    PieCtrlRegs.PIEACK.all|=0x100;      // Issue Group 9, PIE ACK
}

Unfortunately ScibRegs.SCICTL2.bit.TXINTENA doesn't disable the TX interrupt!. I don t know why  and I think I checked everything.

Only disabling the interrupt at the PIE controller really disabled it.

 PieCtrlRegs.PIEIER9.bit.INTx4=0;

So my conclusion is that the SCI TX interrupt system is useless. So please tell me what I did wrong.

Note: I know, I did not send any data, I only checked the way the interrupts are handled.

Hi Evs,

The SCI TX interrupt should work. If there is an issue, we can further investigate. But before that, can you confirm you are setting / clearing bits as specified in Table 13-6 on the F28069 TRM ?Can you also make sure the Autobaud detect is following the steps in Sec 13.1.1.10.3 ?

Thanks

Noah