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.

TMS320F2800157: Pre-mature SPI Tx Interrupt

Part Number: TMS320F2800157

I am trying to set up a Tx FIFO empty interrupt to occur on my SPI slave after writing 7 words to the master. However, I can see that it is entering the interrupt immediately after the interrupt is enabled. Using the debugger, I can see that the registers do not indicate any of the SPI interrupt flags have been set (even the non-FIFO interrupt flag). Even the FIFO status shows 7 words remaining with FFIL set to 0. Is there something I'm missing here?

  • Anurag,

    What is TXFFST and TXFFINT set to? As shown in the attached image, the Transmit FIFO interrupt is generated when the TXFFST and TXFFIL match after the TXFFIENA (TX FIFO Interrupt Enable) bit is set. Ensure that the FIFO levels on the SPI transmit and receive side both set to 7.

    Aishwarya

  • TXFFST is set to 7 and TXFFINT is set to 0, according to the debugger when it enters the Tx FIFO ISR.

    Why do the FIFO levels on the Rx and Tx both need to be set to 7?

  • Anurag,

    Based on TXFFIL settings, interrupt will be generated when the transmit FIFO is 0 which is always the case when enabling the interrupt. There may need to be a change in the interrupt configurations settings.

    In the ePIE as well as the remaining SPI status registers, what are the details stored regarding the interrupt / anything else that may be happening? The SPI interrupt could be happening, but by the time you're reading the values, the flags are cleared.

    Aishwarya

  • So I set the TXFFIL value to 7 on boot and never change it so it should always be 0.

    This is currently the write function for my SPI driver. I have a breakpoint right after the SPI_reset where I check that the FIFO status is 0 using the debugger. I have another breakpoint in the TX FIFO interrupt entry. Hitting run after the first breakpoint, I get to the next breakpoint in the TX FIFO ISR immediately before any bytes are transmitted. I wouldn't anticipate that it enters this interrupt with TXFFINT=0 even if another ISR clears it.

    And just to confirm that Rx FIFO settings do not affect the Tx FIFO interrupt at all, correct?

    I will need to run this test again and gather the ePIE and other SPI register data. The other SPI registers seemed correct as well though with FIFO enabled and no other interrupts enabled other than RX FIFO.

        /* Reset SPI Tx FIFOs */
        SPI_resetTxFIFO(main_spi_BASE);
    
        for(uint16_t i = 0; i < len; i++)
        {
            SPI_writeDataNonBlocking(main_spi_BASE, buf[i]);
        }
    
        /* TODO: Why is the Tx interrupt occurring before the FIFO is emptied? */
        /* Enable FIFO empty Tx interrupt */
        Interrupt_enable(INT_main_spi_TX);
        /* Clear interrupt flag */
        SPI_clearInterruptStatus(main_spi_BASE, SPI_INT_TXFF);

  • Anurag,

    So I set the TXFFIL value to 7 on boot and never change it so it should always be 0.

    In your previous post, you mentioned that TXFFIL value is set to 0? To clarify, if you want a TX FIFO interrupt to occur only when the TX Buffer is empty, you need to set it to 0. Again, the interrupt is based on the level of the buffer not the FIFO itself. Refer to this section again on this configuration (2.3.7 SPI FIFO Description)

    And just to confirm that Rx FIFO settings do not affect the Tx FIFO interrupt at all, correct?

    No, they do not.

    Aishwarya

  • Anurag,

    Have you been able to resolve this issue? If there are no more questions, I will go ahead and close this thread  

    Best Regards,

    Aishwarya