• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 32 subscribers
  • Views 1438 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.

TM4C129ENCPDT: QSSI modes and frame formats

David M. Alter
Guru 61235 points

Part Number: TM4C129ENCPDT

Hello Tiva team,

I am rather confused on the modes of operation of the QSSI in the TM4C129ENCPDT.  Reference the datasheet dated June 18, 2014, Chapter 20.

There seem to be four distinct 'modes' of operation: legacy, advanced, bi-SSI, and quad-SSI.  There also seem to be two difference frame formats: Freescale SPI, and TI-SSI.  Correct?

Per section 20.3.7, it appears I can choose either frame format with any of the four modes.  Correct?  (albeit there are some limitations on the flexibility of the Freescale format in advanced/bi-/quad- mode per the 'note' in the section).

What exactly is advanced mode?  The datasheet doesn't seem to give much of a description of it.  I'd assume it is single TX and RX pins, but then what is the difference between legacy mode TI-SSI format with 8-bit data selected, and advanced mode with TI-SSI format?  They seem to be the same (both have 8-bit frames, and TI-SSI frame format).

Per the end of section 20.3.3, you can switch between different modes on successive transactions in the FIFOs.  Why would someone want to do this?  There seems to be only a single chip-select pin (the frame signal), so you cannot change the device you are hooked up to from inside the QSSI.  I'm not seeing what this switching feature is used for.

Thank you,

David

  • 0
    TI__Guru*** 135355 points

    Hello David,

    David M. Alter said:
    There seem to be four distinct 'modes' of operation: legacy, advanced, bi-SSI, and quad-SSI.  There also seem to be two difference frame formats: Freescale SPI, and TI-SSI.  Correct?

    Correct. I'll add in that Legacy mode supports 4 to 16 data frames while Advanced/Bi-SSI/Quad-SSI support only 8 bit data frames.

    David M. Alter said:
    Per section 20.3.7, it appears I can choose either frame format with any of the four modes.  Correct?  (albeit there are some limitations on the flexibility of the Freescale format in advanced/bi-/quad- mode per the 'note' in the section).

    Correct.

    David M. Alter said:
    What exactly is advanced mode?  The datasheet doesn't seem to give much of a description of it.  I'd assume it is single TX and RX pins, but then what is the difference between legacy mode TI-SSI format with 8-bit data selected, and advanced mode with TI-SSI format?  They seem to be the same (both have 8-bit frames, and TI-SSI frame format).

    I agree Advanced mode isn't well defined, I will try and help fill some of those gaps.

    First off, Advanced mode is the only mode which allows for Full Duplex operation when in RX mode.

    By programming the MODE bits in the SSICR1 register, Advanced, Bi- or Quad- SSI can be enabled.
A direction bit, DIR, is provided to program the direction of operation during a Bi- or Quad SSItransaction.
Since Bi- and Quad-SSI cannot be full duplex, the DIR bit defines whether or not the
RX FIFO is disabled. In Advanced operation, if the QSSI module TX (write) mode is enabled, the
RX FIFO is automatically prevented from receiving any data. When Advanced SSI is in RX (read)
mode, it operates as a full-duplex interface

    Second, Advanced mode offers some unique features along with Bi/Quad mode but without needing to use Bi/Quad mode.

    For example, SSInFss functionality (Section 20.3.4) is a point where Advanced mode has solved issues for customers. Without using Advanced mode, when trying to send out more than 16 bits of data (max length via Legacy mode), it would not be possible to do so without a gap between bytes of data even if manually holding the SS line down via GPIO (if using SSInFss, Legacy mode will even force the SS line high between bytes). I.E. it isn't possible to send, say, 24 bits of data continuously without Advanced mode. With Advanced mode, as long as the TX FIFO is loaded in time, multiple data bytes can be streamed out without any delay between bytes, allowing for the creation of larger packet sizes such as 24 bits. Of course care must be taken in such a case, as the FIFO is limited to 8 bytes, but proper coding will allow the FIFO to be loaded correctly to achieve such functionality.

    That is just one example, but the larger point is that there are features shared by Advanced/Bi/Quad mode that can be very beneficial for certain SSI operations, so while Advanced mode doesn't get it's own section, those features can give Advanced SSI mode more flexibility compared to Legacy mode for certain applications.

    David M. Alter said:
    Per the end of section 20.3.3, you can switch between different modes on successive transactions in the FIFOs.  Why would someone want to do this?  There seems to be only a single chip-select pin (the frame signal), so you cannot change the device you are hooked up to from inside the QSSI.  I'm not seeing what this switching feature is used for.

    Honestly, I am not sure myself, it has not yet come up during my time supporting these devices. Sometimes not all features listed prove useful. Maybe a community member may have experience doing so and can comment on the utility of it though.

  • 0 in reply to Ralph Jacobi
    Guru 117855 points

    Ralph Jacobi said:
    David M. Alter
    Per the end of section 20.3.3, you can switch between different modes on successive transactions in the FIFOs.  Why would someone want to do this?  There seems to be only a single chip-select pin (the frame signal), so you cannot change the device you are hooked up to from inside the QSSI.  I'm not seeing what this switching feature is used for.  

    Our firm has encountered (several) highly specialized SPI Slave devices - which 'appear' to be a 'blend' of two unique, such SPI devices.     This 'creation' aimed at a (very) unique (i.e. 'blended' capability) - most quickly/easily realized - by this 'unholy  duality.'      

    I am careful to make 'no claim' that such 'is' the (only) explanation for such 'on-the-fly,  mode switch.'     Instead this is what  we (have) encountered - and has been 'offered up'  -  out of respect for - and friendship - w/vendor's Ralph...   (per his appeal - posting above)

    I believe that a 'broader search' of ARM MCU Vendors (may) further reveal the 'intent & handling'  of such (on-the-fly, mode switching) devices.      All such 'key/novel information' - rarely resides - in 'one & only one' - source and/or locale.     (thus my group often urges the use of, 'Vendor Agnostic' - Development Tools/Hooks/Methodologies.)

    Note too - poster relies upon a CY2014 data presentation - less than optimal - for 'real and/or efficient'  'Advanced' info gleaning...

    Our encounters were w/in (both) Medical & Defense Apps - thus not 'much more to say.'    And - we  are told - there are reports of this technique - even further expanding...    (unholy 'trinity' - anyone?)
  • 0 in reply to cb1_mobile
    TI__Guru*** 135355 points
    Hi cb1,

    Thanks for offering your experience with that feature, much appreciated!! *LIKE*
  • 0 in reply to Ralph Jacobi
    Guru 117855 points

    You Sir - are most welcome.

    I was pleased w/my creation of, 'unholy duality!'     Extending that to 'trinity' ... has been done (many, many times) before!'

    Somehow (now) the introduction of 'hybrid' - rattles across this thread...  (cannot hold a candle to 'unholy duality')

    I'm sailing this week w/a guy who knows 'more' - if there's real interest expressed - I (may) ... 'tease (further) out.'     (again though - another ARM vendor offers up greater (and FAR MORE Current) detail ... such 'broad-based'  superior investigatory skills - always ADD VALUE!)

    The 'sudden' interest - in such an arcane 'MCU Detail' - by a 'technical staffer' - proves curious.      (perhaps (even) warrants explanation...)

  • 0 in reply to cb1_mobile
    TI__Guru 61235 points
    Thank you Ralph and cb1.

    - David
  • 0 in reply to David M. Alter
    TI__Guru 61235 points

    Ralph,

    I have a follow-up question.  Suppose you have two TM4C devices talking to each other using the QSSI in Advanced mode.

    One device needs to have DIR=1 which is transmit mode.  Which pin does the data come out on (e.g. SSInXDAT0/TX)?

    The other device needs to have DIR=0 which is receive mode.  Which pin does the data get received on (e.g., SSInXDAT1/RX)?

    Reason I ask is if the pins I cited above are correct, this requires cross-wiring the pin connections, e.g. D0->D1.  This is not compatible with the half-duplex bi- and quad- connections, which are straight D0->D0, D1->D1, ... .

    Thank you,

    David

  • 0 in reply to David M. Alter
    TI__Guru*** 135355 points
    Hello David,

    The TX and RX indicators the GPIO are specifically for Legacy Mode where that functionality is locked. For Advanced mode I believe you should be able to set D0 of one device to TX, and D0 of the other device to RX. I don't see any specific pin configurations on a GPIO level which would prevent you from doing this, and the registers for SSI also do not raise any red flags.

    However, I don't think Advanced mode was ever intended to be used for device-to-device communication with other TM4C devices like what you are describing, and we don't have any examples of doing this, so I would advice testing out that operation prior to board layout to validate that there isn't an unexpected limitation present.
  • 0 in reply to Ralph Jacobi
    TI__Guru 61235 points

    Ralph,

    Thank you for the quick response.

    Ralph Jacobi said:

    For Advanced mode I believe you should be able to set D0 of one device to TX, and D0 of the other device to RX. I don't see any specific pin configurations on a GPIO level which would prevent you from doing this, and the registers for SSI also do not raise any red flags. 

    I may be missing something, but I don't see any registers that allow you to change the pins that TX/RX are assigned to.  How would you do this?
    Regards,
    David
  • 0 in reply to David M. Alter
    TI__Guru*** 135355 points
    Hello David,

    From what I was reading, the key is to set the DIR bit based on your intended operation. I believe the same pin could be used for both TX and RX because I don't see a way you can set Advanced mode to use two pins where one is TX and one is RX and still get the benefits of Advanced mode. The method I see working would be that you'd set Device 1 to TX with DIR = 0, and Device 2 to RX with DIR = 1.

    This is based of this comment from the datasheet: "In Advanced operation, if the QSSI module TX (write) mode is enabled, the
    RX FIFO is automatically prevented from receiving any data."

    Therefore, you'd need to toggle the DIR bit based on what you are seeking. I don't see a setting to say 'SSInXDAT0' is TX and 'SSInXDAT1' is RX while in Advanced mode.

    As you can see, for an MCU to MCU communication setup, that is hardly ideal, hence my comment that the Advanced SSI mode was not exactly intended for what you are trying to achieve here.

    The only other alternative possibility is I am wrong about the means to use a single line as described and that Advanced mode would require both a TX and an RX line, but the DS doesn't indicate this as it mentions Legacy mode pin assignments only. Furthermore, the DS does not offer any configuration to determine what pin is TX vs what pin is RX, so I really don't see a way to get SSInXDAT0 to connect to SSInXDAT0 for TX only and SSInXDAT1 to connect to SSInXDAT1 for RX only.
  • 0 in reply to Ralph Jacobi
    TI__Guru 61235 points
    Hi Ralph,

    The same section of the datasheet 20.3.3 also says

    When Advanced SSI is in RX (read) mode, it operates as a full-duplex interface.

    So for full-duplex, I assume TX is on SSInXDAT0 and RX is on SSInXDAT1. I'd also assume that in write mode, TX is still on SSInXDAT0.

    Would you agree?

    I don't see any way to change these, regardless of what you do with the DIR bit.

    Thanks again,
    David
  • 0 in reply to David M. Alter
    TI__Guru*** 135355 points
    Hi David,

    Good call out, my mind glazed over the fact that mentioning full-duplex means that would require a second line, so it must need both a TX and RX line in that case then. However that means we'd now be in the situation of "Furthermore, the DS does not offer any configuration to determine what pin is TX vs what pin is RX, so I really don't see a way to get SSInXDAT0 to connect to SSInXDAT0 for TX only and SSInXDAT1 to connect to SSInXDAT1 for RX only." so you'd be bound to the restraint of crossing wires still.