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.

TM4C123BH6PZ: SSInFss Timing

Part Number: TM4C123BH6PZ

In developing for the TM4C I am using the SSI peripheral with the following settings: Freescale SPI with SPO=0 and SPH=0. With these settings the SSInFSS is toggled between each word of information on a continuous transfer. In looking over TI resources for this microcontroller I can find no minimum timing that SSInFSS is pulsed high between each word transmitted in a continuous transfer. I imagine this timing is somehow variable depending on system clock or the serial clock frequency. While it might be determined empirically for a given device I imagine there might be some variation between devices as well. So, is there at least some minimum timing or some specification on this parameter that would be adhered too for all manufactured parts of particular revisions?

  • Hello Erik,

    Is there a specific need for the SS line to be pulsed high between words for a continuous transfer? In all my experiences with SPI communications, I have never configured it so that SS goes high between each word when there is a constant stream of data being sent out. Rather, the SS line stays low until all bytes are being transmitted.

    With that in mind, as that is the typical usage for SPI, I don't think we ever spec'd out a minimum timing for the SS line to pulse high between words.

    Can you elaborate your use case that requires the SS line to be pulsed high for a continuous transfer?
  • Hi Ralph,

    The high pulse on the FSS pin is described in the datasheet as follows. However, in the datasheet the minimum high width of the FSS during the continuous transfer is not specified. I will tend to think that the min be very small, perhaps one SPICLK. Since this information is not characterized the data will need to come from empirical experiment.

    In the case of a single word transmission, after all bits of the data word have been transferred, the
    SSInFss line is returned to its idle High state one SSInClk period after the last bit has been
    captured.
    However, in the case of continuous back-to-back transmissions, the SSInFss signal must be pulsed
    High between each data word transfer because the slave select pin freezes the data in its serial
    peripheral register and does not allow it to be altered if the SPH bit is clear. Therefore, the master
    device must raise the SSInFss pin of the slave device between each data transfer to enable the
    serial peripheral data write. On completion of the continuous transfer, the SSInFss pin is returned
    to its idle state one SSInClk period after the last bit has been captured
  • Hello Charles,

    I see, thanks for sharing that. I wonder if that's only for when SSInFss is used then? Looking back at the SPI example for TM4C I am familiar with, another GPIO was used as an SS, so the SSInFss pin for that SPI base wasn't used. In that application, the continuous byte transfers kept SS low throughout all bytes output and then raised it high when a continuous transfer concluded.

    I suppose if the SSInFss pin isn't configured/used, then the peripheral register will just allow for the next data to be written without an SS pulse?
  • Hi Ralph,
    I modified the TivaWare ssi example and simply created a few SSIDataPut() consecutively. I could see the FSS pin goes high after each word. Without the FSS pin configured, I will still see the SPI go Idle between words as the SPICLK will be inactive during the Idle period. The FSS is just low throughout.
  • The application in usage is communication between this processor and an FPGA. The concept would be to accept a word of information, parse through the word contents that had been transmitted. In doing so the following word to be transmitted would be based on the previous word received. However, in order to do this adequate time would be needed between transmissions. The SSInFSS going high between transmissions on the SPO=0 & SPH=0 for continuous transmissions could have provided this time period potentially.

    Though since the information cannot be guaranteed for some minimum time period I suspect there might be some variation between parts that it would be preferred not to assume unless it was specified by the datasheet. However, I can think of some alternative strategies to my specific application such performing only one transfer at a time. Utilizing the aforementioned method with the SSInFSS pin would have simplified some things.

    Thank you Charles and Ralph for your help.