• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 33 subscribers
  • Views 3136 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.

TM4C123GH6PM: SSI module - how to safely switch between mode 0 and mode 1

Jan Juranek
Intellectual 310 points
Part Number: TM4C123GH6PM

Hello guys, I'm trying to solve issue on SSI module. I have to devices on one bus. One is is "mode 1 device" and one is "mode 0 device". How do I propertly change SSI modes?

On the beginning I send data to "mode 0 device" so I call this function to set up SSI module:

SSIConfigSetExpClk(SSI3_BASE, SysCtlClockGet(),SSI_FRF_MOTO_MODE_0, SSI_MODE_MASTER,500000 ,8 );

When I want to send data to "mode 1 device" I call the same function, but with another mode parameter:

SSIConfigSetExpClk(SSI3_BASE, SysCtlClockGet(),SSI_FRF_MOTO_MODE_1, SSI_MODE_MASTER,500000 ,8 );

My question is if this is a good practise or I have to Disable module, change parameters and enable module.

Thank you,

Jan

  • 0
    Guru 117855 points

    Jan Juranek said:
    ...using SSI module ... I have two devices on one bus.

    While not stated - there must be separate "chip-selects" for each device - is that not true?

    Now neither firm nor I have ever "switched between modes" - as you propose - yet the "independence of chip selects" should properly "isolate" each slave device.     Unknown or in question then is, "How or If the MCU will prove accepting of this, "On the fly" mode changing."    

    In absence of "direct factory guidance" - would not your scope capture of  "each SPI mode's bus transactions" - both "before and then after" such mode change - provide (some) insight & comfort?    

    I suspect that "best practice" would see you, "Disable the SPI module" prior to such change.    (that should not enforce much of a time penalty)    While the MCUs you have now (may) appear to function well w/out the "safety of disabling" - that behavior may (not) continue into the future - especially if MCU process changes are introduced.

    With "little to be gained" by "bypassing the peripheral disable" - I'd opt for the safety and "known conditions" which are more assured - under that "more controlled" (disable prior to mode change) approach.

  • 0
    TI__Guru**** 190406 points
    Hi Jan,
    If you can make sure the FIFO is fully drained and all outstanding SPI transactions are fully complete then you can change mode. But to be on the safe side, please take the suggestion from cb1 to additionally disable the SPI before you switch mode.
    We have other TI MCU with SPI that supports multiple CS and with capability of different format/mode for each CS. The SPI's internal kernel takes care of switching between modes for different CS. This is not the case with TM4C. So the application must ensure the mode switch is done is a very clean manner.
  • 0 in reply to Charles Tsai
    Guru 117855 points
    G'Day Charles,

    As one perhaps (more) involved in the business/finance side of Tech (than most here) the concept of, "Risk-Reward" should be noted.

    While the poster is to be applauded for recognizing & presenting the issue - any "gain" achieved seems "slight" - and the "risk" appears presently unknown (due to the "rarity" of such, "on the fly" mode change) - thus, "Caution should prevail." (i.e. as poster noted - "Disable of the Peripheral - prior to such (repeated) mode change - is preferred...)
  • 0 in reply to cb1_mobile
    Guru 10570 points
    I don't see any reason to disable the SPI module between selections. What you do need to do is verify that the peripherals will turn off their interfaces when de-selected. I have seen 'SPI peripherals' that still react to the clock even when de-selected.

    Another restriction would be that you probably shouldn't use the built-in FSS of the SPI peripheral (You probably shouldn't use that in any case, it's more trouble than it's worth).

    In the worst case you add a buffer with an enable (hooked up to your CS line) in front of the peripherals to ensure they see no disturbance when not selected. Note that if you need this protection with the SPI enable when changing modes, you also need it if you disable the SPI when changing modes.

    Robert
  • 0 in reply to Robert Adsett72
    Guru 117855 points

    Robert Adsett72 said:
    I don't see any reason to disable the SPI module between selections.

    I do - and will detail further.     As such, "On the fly" mode switching is (relatively) rare here - it is doubtful that such has received the vendor's (normal/customary) exhaustive, "suite testing."     That introduces an "element of risk" - does it not?      (even if the gremlin occurs upon the 20th - or even higher count - of such, "On the fly" mode changes.)

    While you, "don't (yet) see any reason" - it is doubtful that "inviting potential risk" (via neglecting to return to safe/known "initial conditions") makes great sense.     And - while no one doubts your past experience - as you/I have often stated - "Every case proves unique!"

    I totally agree that, "de-selection" of the slave(s) may reveal issues - and "must" be test/verified.    (you've seen "reaction to the clock" - I've seen (Slave Data Out) "capture the bus!")

    As to, "Changing Modes" - I'd (positively) disable both devices (make any/all chip selects INACTIVE) prior to (any) such "Disable or Enable" - prior to SPI mode change.

    i believe that the fact is we, "just don't know" the potential impact of such "mode change" - and (some) defense (i.e. poster's suggested Disable/Enable - aided by my "Deselection of each/every Slave" prior) should serve as a beginning test method.    (of course subject to further, in-depth review by poster - and his "acceptance" than any new/changed SPI Slave may "not react" in a similar manner.)

  • 0 in reply to cb1_mobile
    Guru 10570 points

    cb1_mobile said:
    Robert Adsett72
    I don't see any reason to disable the SPI module between selections.

    I do - and will detail further.     As such, "On the fly" mode switching is (relatively) rare here - it is doubtful that such has received the vendor's (normal/customary) exhaustive testing.     That introduces an "element of risk" - does it not?      (even if the gremlin occurs upon the 20th - or even higher number - of such, "On the fly" mode changes.)

    A-priori, I'd place it as a slightly smaller risk than repeated enabling/disabling the module. Also easier to verify.

    cb1_mobile said:
    I totally agree that, "de-selection" of the slave(s) may reveal issues - and "must" be test/verified.    (you've seen "reaction to the clock" - I've seen (Slave Data Out) "capture the bus!")

    Good point, I've seen that as well. It's worth noting that both these risks exist even if both peripherals are able to use the same mode.

    cb1_mobile said:
    As to, "Changing Modes" - I'd (positively) disable both devices (make any/all chip selects INACTIVE) prior to (any) such "Disable or Enable" - prior to SPI mode change.

    No question. And this requirement is a part of my reasoning for not using the SPI built-in slave select.

    -------

    It occurs to me that there is (possibly) a third option. Some of the SPI modes can be converted to another by the appropriate insertion of inverters into the clock (or in some cases data) line. If this can be done, then you avoid the need and risk of changing modes. You would need to first draw out the waveform and compare it to the data sheet requirements and then measure it with an oscilloscope/logic analyzer to verify the timing but that's really something you need to do in any case.

    Robert

  • 0 in reply to Robert Adsett72
    Guru 117855 points

    Robert Adsett72 said:
    Some of the SPI modes can be converted to another by the appropriate insertion of inverters into the clock (or in some cases data) line.

    Rather than DESTROYING the "LIKE" - hallowed (all knowing) forum gods should have created, "REALLY LIKE!"

    REALLY LIKE ..... REALLY LIKE ..... REALLY LIKE ..... REALLY LIKE .....REALLY LIKE

    Tres bien, Monsieur!    (such explains the (flow) of "big bucks" at/around your (oft frozen) tundra.)      The inverter must be reasonably fast - so as not to introduce "set-up and/or hold" violations.   A great - "Problem Reduction" - if not full Problem Solving) idea!      Very well done.     (and often - far easier to "bend the hardware" - rather than "swim upstream" - especially when those "upstream waters" [*] prove murky/unknown!)  

    Note too that one can (always) find use for the (remaining) inverter sections.    (or employ a "mini - single inverter" (sot-23).)

    [*]  (Slave & MCU's handling of Mode Change and/or Disable)

  • 0 in reply to cb1_mobile
    Guru 117855 points

    In the further interest of, "Indirect MCU Problem Solving" - via "changed conditions - external to the MCU" - another approach dawns.     As only two SPI Slaves are "in play" - how hard can it (really) be - to find Slaves w/identical SPI operating  modes?     And - in fact - was such an approach (even) considered?

    This method eliminates (both) SPI Mode Switching and all demands for "external hardware" - thus should receive full consideration...   (It is "unlikely" that poster had executed a rigorous search for "Mode Sharing Slaves" - and that (weakness) lead directly to this (mode sharing) dilemma.)

    In conclusion - poster sought, "To Safely Switch between SPI Modes."       Might the best (and purest) means of meeting that "safely" goal result (clearly) from, "REFRAINING FROM SWITCHING?"     (i.e. choose devices which share the same Slave Mode or are "flexible enough" to enable the Slaves to "select, thus match" SPI modes...)

  • 0 in reply to cb1_mobile
    Guru 27665 points

    cb1_mobile said:
    As only two SPI Slaves are "in play" - how hard can it (really) be - to find Slaves w/identical SPI operating  modes?  

    Even better.  Although how hard will depend on exactly what the ICs do.

    Robert

  • 0 in reply to Robert Adsett
    Guru 117855 points

    Thank you - twas you who, "Led the way" by suggesting, "Non-MCU" means to "resolve."    I merely followed your "freshly blazed trail" - and even w/"inexpert (i.e. staff produced) moccasins" - that trail led to a neat "clearing!"       (NO Switching trumps "risky" Switching!) 

    System components should be chosen based (both) upon functionality & "ease of integration."       (It is doubted (still) that such "integration" received fair/proper recognition...)