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.

Help needed explaining SPIFIFO working mode

Other Parts Discussed in Thread: CONTROLSUITE

Hi all,

I am using SPI for data transmission, and I have some problem reading SPIFIFO example project in ControlSuite. The main source file in this project is: Example_2833xSpi_FFDLB.c. My question is:

1. How is SPITXFIFOISR and SPIRXFIFOISR triggered? Is SPIRXFIFOISR triggered right after the completion of data reception? Does SPITXINT stands for the completion of data transmission, that CPU will go deal with SPITXFIFOISR after one data transmission?

2. When does SPI data reception and transmission start? Is it running continuously, and what's the time interval? I know that the SPI data reception starts when SPISTEA give the enable signal to the sender. Is this process stopped during RX/TX ISR? After completion of this ISR, when will data transmission or reception restart?

3. Is there any way I can fix data reception and transmission rate(not baud rate of data)? I tried to program SPI(not using SPI interrupt) in internal interrupt generated by CPUTimer0 of which time interval is fixed, but it doesn't work. The problem now is that in the CPUTimer0ISR, SPIINT.FLAG which indicate the completion of data reception will never set high, and the program will get stuck in the while loop iteration like shown below. Is it feasible for me to do so? Can I realize it using SPI interrupt?

Any help is appreciated! 

Thanks,

Hezi

  • Hi all,

    I have a problem with SPI transmission.

    1. In my application, SPI is used to drive "chip selection"  end of an ADC chip and store received data in SPIRXBUF. I need to receive one data transmitted from SPI and do some computation, so SPI transmission is not consistent. Also, I need to remain an fixed sampling frequency, so I decided to use interrupt to trigger my SPI transmission. This interrupt is triggered by CPUTimer0 and is shown below. My main function is just an infinite for loop waiting for this interrupt.

    When viewing SPI transmission result, I found the value of (SpiaRegs.SPIRXBUF<<2) was always 0, which means the subroutine didn't even complete and jump back to main function. On the contrary, using SPI transmission with program of line 450 to 455 in main function directly would give me  correct value. It seems to be trapped in the while loop if used in interrupt subroutine. Does anyone know how was this happened?

    2. My application is very time sensitive, and in order to realize my purpose it's better for me to make use of every clock cycle. In the program, CPU is waiting while SPI haven't finish all 16 bits transmission(the no operation period in while loop). SPI won't work if I modified this SPI program to be other way. And this is also the way in ControlSuite example projects. I am confused that if we configure SPI to work automatically according to clock setting, is it possible for me to modify SPI transmission program to make full use of the clock cycles while waiting? And how can I do it?

    Any help is appreciated!

    Doris

  • Hello,

    Is there a particular reason why you aren't using the SPI receive interrupt to let you know that the transmission was completed instead of using a while loop? Have you tried it? There's an example in controlSUITE called "Example_2803xSpi_FFDLB_int" that demonstrates the setup.

    Thanks,
    Whitney
  • Hi Whitney,

    Thanks for your reply. I was having trouble understand SPIFIFO working mode: how does the transmission happen? If in my application, I first use my board to receive data, and this data should be received and stored in SPIDAT register. Then I want to transmit this data out, when will this transmission take place? Is SPITXBUF cleared right after the transmission, and SPITXINT triggered afterwards, then SPIDAT register value loaded to SPITXBUF for next transmission in SPITXFIFOISR? And the same problem bothers me for the receiving process: when does the receiving starts to happen? How often does it take place? Is receiving/transmitting running continuously, but not during the time which CPU is dealing with interrupts?

    Thanks,
    Doris
  • If you have not already, please read about the FIFO operation in the reference guide.

    http://www.ti.com.cn/general/cn/docs/lit/getliterature.tsp?baseLiteratureNumber=SPRUEU3&fileType=pdf

    To answer questions 1 and 2, the FIFO interrupts are meant to occur when the FIFOs are at a specific level of fullness. They tell you about the FIFO status. They do not cause the SPI operation to halt or anything like that. For example, say you want to get a SPIRXINT when at least two words have been received and are in the FIFO. You would set SPIFFRX.RXFFIL equal to 2 in your configuration code. So when two words have been received and have yet to be read out of SPIRXBUF, the SPIFFRX.RXFFST field will be equal to 2 and an interrupt will occur.

    To answer number 3, I don't know what you're sending and receiving data from, but I'm not seeing any issues with initiating the transmission by writing to SPITXBUF in the timer ISR. However, instead of a while loop in the timer ISR, using an SPI interrupt to let you know that  you received data should be feasible.  Then you can read the data from SPIRXBUF in the SPIRXINT ISR. Since you'll be using the timer ISR to initiate the transfer, I don't think you need to bother with the SPITXINT interrupt.

    It might be helpful for you to do a quick exercise where you take Example_2833xSpi_FFDLB_int and modify it to send data from a timer ISR instead of the SPI transmit ISR. Once you've got it working in that loopback example, maybe it will be clearer on how to do it in your project.

    - Whitney

  • Hi Whitney,

    I've already solved this problem, and my code is incorrect for trying to call SPI transmission function in the internal CPUTimer interrupt. So I use SPI interrupt and remove this part out of CPUTimer interrupt, and it's working perfectly fine.

    Thanks for your help!
    Hezi