• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 82 subscribers
  • Views 226 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.

TMS320F28377D: What if the SPI host reads more than 16 words continuously at a set baud rate?

yutao liu
Prodigy 65 points
Part Number: TMS320F28377D


Tool/software:

We know that although the SPI communication is full duplex, it needs to read the data of the slave machine, the way is that the host actively sends data to the slave machine to read, and the receiving and sending cache of the 28377D chip is only 16 words;


If I want to continuously read more than 16 words of data, the following problems arise:
1, when I SPI hosts sent 16 bits of data (using a for loop to send, for reading SPI data from machine), my SpiaRegs SPIFFRX. Bit. RXFFST only two words, this cause I have to stop to the SPI read from the machine (that is, stop sending), Otherwise, I will lose the following data;

How can I make the SPI host read more than 16 bits of data continuously?? Remember is continuous!! Instead of reading every 16 bits, it is one time!!

Hope to see this post of technical staff can help me solve this problem, thank you!!

  • 0
    TI__Genius 11076 points

    Hello,

    Unfortunately, you're running into a limitation of the system. As described in the device TRM, the maximum packet size is 16 bits. The simplest solution to your problem, and the one I would recommend based on the provided information, is to shorten your packet size and send multiple packets when necessary. Alternatively, I believe there are SPI-DMA schemes which facilitate something like this, but that is more complex to develop, and I don't recall the methods currently. If it is not at all possible to shorten the packet size, please let me know.

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    Prodigy 65 points

    Yes, just as you said, so I tried the SPI-DMA solution (using DMA to store the data received by SPI), which did solve the problem of SPI receiving length, but I also encountered another problem, which is: when the DMA receiving length is equal to my SPI data length, I read the data in the DMA storage buffer and found that it must wait for 238 instruction cycles to update after that, otherwise I will not be able to read the latest data. I want to know if this is a problem with my software configuration? Because I read the manual, the manual says to update the data in the DMA storage buffer first, and then increase the receiving length. Therefore, I think that as long as the DMA receiving length is equal to my SPI data length, I can immediately read the stored data in the DMA without waiting for 238 instruction cycles. And I also hope to get the exact time point when the DMA data buffer data is updated, thank you.

  • 0 in reply to yutao liu
    TI__Genius 11076 points

    What is your SPI data length? That's quite a long length, certainly longer than I would expect.

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    Prodigy 65 points

    I am now using DMA.CH5 for SPITX and DMA.CH6 for SPIRX, and I want to know when the SPI data is sent and received (by what flags?).

  • 0 in reply to yutao liu
    TI__Genius 11076 points

    Apologies for the delay in response. Based on your most recent reply, did you resolve the prior issue with the delay in DMA updates?

    For determining when the DMA completes a transfer, you can configure the DMA interrupt to trigger on the end of a transfer operation. Each DMA channel is capable of generating independent interrupts.

    Regards,
    Jason Osborn