• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 664 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.

CCS/TM4C123GH6PM: Frequently SPI communication between 2 TM4C123GH6PM

Nam Vu
Prodigy 250 points
Part Number: TM4C123GH6PM


Tool/software: Code Composer Studio

Dear all,

I'm working on a project that requires communication between 2 TM4C123GH6PM. The Slave handles a power process that shouldn't be interrupted , and the Master frequently sends request (R/W data) to the Slave. The Slave only process and response whenever the power process is done, this process is looped infinitely. Currently, I'm able to communication between 2 kits continuously and using SPI interrupt.

I found out that the Slave can only response when the Master puts data on the Tx line (which enables the SPI clock). If SPI clock always active, the Master and Slave only need to send data once in order to utilize the usage of full-duplex characteristic. Is there any way to always active the SPI clock?

If that method is impossible, I also found a plan B for this problem. The Master will frequently send data to Slave, whenever the Slave is in power process, it will clear the FIFO and continue the power process. Only until the Slave reaches to the Communication process, it can process and response the request. In order to effectively explaining the concept, I made a figure so that you can understand my idea easier (the figure is attached below). Is my method good enough? If there is any other solution that more effective than this, please show me the way.

Thank you.


  • 0
    TI__Guru*** 135355 points
    Hello Nam,

    See my comments here RE: endless SPI clock: e2e.ti.com/.../2923541

    As far as method 2, that seems reasonable to me since this sounds like a closed loop system so the master can be certain to understand what a non-reply means.

    You may also want to look into if you can use another form of communication like I2C. For I2C, the master would release control of the clock which would let the slave have more control of when to reply. Just another idea.
  • 0 in reply to Ralph Jacobi
    Prodigy 250 points

    Hello Ralph,

    It's good to see you again. Thank you so much for your support.

    The endless clock is so brilliant, I will definitely try it. Currently, I have successfully coded the program based on the second method. The reason why I don't use the I2C communication because I program on TM4C123, and it doesn't have FIFO. 

    The FIFO of module SSI0 is 16-bit x 8, thus I send a frame of 4 uint32_t data between 2 Tiva. The Master's sweeping period is about 10 times of the Slave's. So the Slave will always receives data package from Master, but only response when the power process is done. I wonder about the occurrence of Receive timeout, whenever it happens, the process will have to stop to use the SSIDataGet(SSI0_BASE,&data) in order to clear the FIFO (please tell me if I wrongly clear FIFO). The delay time for clearing FIFO may cause the discontinuous in the power process. Is it okay if I will just let the FIFO receives data but not get out? Can it cause any overloading?

  • 0 in reply to Nam Vu
    TI__Guru*** 135355 points
    Hello Nam,

    The I2C doesn't have a FIFO because of the ACK/NAK system it uses. If the Master sends a packet and the slave is not ready for it, you would see a NAK and then can try sending again. This would let you avoid the need for a FIFO.

    You bring up a good concern with the SSI FIFO, depending on how much data is sent into it, it may overflow and trigger a Receive FIFO overrun.

    Another thing you can look into perhaps is using the uDMA to handle the SSI transactions as that would run during otherwise-idle bus cycles and wouldn't impact your power process.
  • 0 in reply to Ralph Jacobi
    Prodigy 250 points

    Hi there,

    Thank you for your suggestion. I just know about uDMA for a couple of days, hence, extremely lack of experience in this module. I will do more researches to config uDMA in order to solve the asynchronous communication problem.

    About the endless SPI clock, I find that is a little bit difficult for me since the Data only transferred from Slave to Master when the Chip Select is active low. I will try to do it by using Slave's GPIO as a replica of Chip Select.

    Best Regards,

  • 0 in reply to Nam Vu
    TI__Guru*** 135355 points
    Hi Nam,

    The other challenge will be timing data output to be proper with clock signal. You may need some interrupts to help drive that. For the side that generates the clock it is not too hard but for the other side it could be tricky. Just something else to keep in mind.
  • 0 in reply to Ralph Jacobi
    Prodigy 250 points

    Hi Ralph,

    Thank you for your warning. The endless clock SPI communication is really tricky indeed, I will find the way to adapt and improvise this kind of problem. Btw, I'm working on the UART uDMA as a plan C since you suggested; and I found it is kinda hard for me to setup and control the channel flow. I have done some researches and asked my professor about the basic knowledge of uDMA, but I still struggle with it because working with registers is not my strength. I will try to find out the way, and if I'm stuck again, please help me out (in other topic).

    Best regards,

    Nam