• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 80 subscribers
  • Views 827 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.

MSP432E401Y: FSSHLDFRM and SSI Legacy mode

Bruce McKenney
Guru 100965 points
Part Number: MSP432E401Y


I need to integrate an SPI device on a board revision (msp432e401y). It appears I will not have the opportunity to try it first, so I need to get it right the first time.

The device expects /CS (Fss) to be asserted for the entire (many-byte) transaction. I want to make sure I can run it in Legacy mode, and I would prefer to connect Fss to the slave's /CS. It can run in either mode 0 or 3. 

Apparently "continuous back-to-back" [ref TRM 23.3.7.3 ff.] means "don't let the FIFO go empty", a dynamic requirement I'm not sure I want to agree to. If it comes to that, I don't mind connecting the slave /CS to a GPIO and wiggling that directly, but I need to know that at design time (i.e. now).

I homed in on FSSHLDFRM. Amit Ashara seemed to confirm that I'm in the right vicinity:

https://e2e.ti.com/support/microcontrollers/other/f/908/t/353108

My remaining concerns:

1) TRM (SLAU723A) Table 23-2 says that Legacy+FSSHLDFRM=1 is "Not a valid combination", followed by (paraphrasing) "This is what Bruce should use". In what sense is this combination "not valid"?

2) Amit Ashara's response suggests that I Must set FSSHLDFRM=0 Before transmitting (loading the FIFO with) the last byte. I foresee a certain amount of clumsiness. Does it still work if I set it to 0 after the last byte is sent? (Think /CS as a GPIO.)

Thanks for any suggestions.

  • 0
    Guru 100965 points

    My neuron finally fired, and I remembered I can do the important experiments without having a slave device.

    1) FSSHLDFRM+Legacy seems to work as expected, i.e. it seems not-very-"not-valid". Maybe I should submit a doc-change request.

    2) I can set FSSHLDFRM=0 any time after I've loaded the last transaction byte into the FIFO. It's fine if that byte has already been sent.

    Additional:

    A) As described in the book, SPH matters -- with SPH=0  setting FSSHLDFRM=0 has an immediate effect (rather than when the FIFO empties). My device does mode=3, so that's fine.

    B) SSISR:BSY is apparently set as long as FSSHLDFRM=1, so you can't (per /CS conventions) wait for the SSI to go idle then set it to 0. This is fine due to (2) above.

  • 0 in reply to Bruce McKenney
    TI__Genius 15590 points

    Hi Bruce,

    I'm glad you were able to resolve your issue, thanks for sharing!

    BR,

    Alexis

**Attention** This is a public forum