TM4C129X datasheet does not state which SSI pins are MISO and MOSI - even more confusing - they are labelled "bi-directional" !

Peter John said:

even more confusing - the pins are labelled "bi-directional"  !  Sureley MOSI and MISO are unidirecitonal.

Feel your pain - yet might you have missed the fact that this (relatively) new MCU now supports both BI & QUAD SPI data transfers.  And - in those incarnations - (despite your assertion of "surely") bi-directional data transfer is (indeed) provided!

That said - the manual data you've nicely provided - fully answers your concern!

SSI0XDAT0......SSI0TX in Legacy SSI Mode....which is MOSI in your terms

SSI0XDAT1......SSI0RX in Legacy SSI Mode....which is MISO in your terms

Indeed the manual should better specify - as past tech-writer - the mass of data & extreme device knowledge sometimes "dulls" (normal user) needs/awareness.

Hello Peter,

On the connection part the pins need to be swapped. For a slave the SSIXDAT0 is the MISO pin and SSIXDAT1 is the MOSI pin.

Regards
Amit

cb1 Thank you for your reply and sympathies ! Your answer makes sense, and yes it had crossed my mind that the bidirectional claim was related to the BI and QUAD SPI transfers.

Hi Amit,
your answer confuses me after I read and agreed with cb1's response. He (rightly?) wrote that

"SSI0XDAT0......SSI0TX in Legacy SSI Mode....which is MOSI in your terms"

I understood that to be MOSI on both the slave and master

then you wrote:

"SSIXDAT0 is the MISO pin " and "SSIXDAT1 is the MOSI pin"

which contradicts cb1 and the datasheet (assuming Tx=MOSI and Rx=MISO). Do you have your MOSI and MISO reversed ?!

Amit Ashara said:

the pins need to be swapped. For a slave the SSIXDAT0 is the MISO pin

Good grief - quelle disaster!  

Not your doing - but does this "reversal" of poster's MCU manual data continue - when the MCU is in Master mode?

And - is the MCU manual data incorrect (as presented, this thread) in regards to SPI pinouts?

And to poster Peter - I based my response (entirely) upon your good inclusion of MCU SPI data from (one assumes) the MCU manual.  Any "reversal" of those pins is (indeed) Krazy making!  Good grief!

Here again from p.1228 of the official datasheet for TM4C1294NCPDT clearly showing SSI0XDAT0 =Tx (=MOSI)

Amit, cb1, please confirm once this apparent reversal is sorted out that I always connect  Master MOSI (SSI3XDAT0)  to Slave MOSI (SSI0XDAT0) and Master MISO to Slave MISO, as per my initial post ?  I'm going to sleep now (2AM in Sydney !) so I'll answer again later.

Would love to - but we've not used these '129 devices (prefer other, faster) ARM M4 MCUs - which some (way/how) avoid this signal "reversal" SPI uncertainty when in quad, bi or single bit SPI modes.

Again - I responded strictly upon your submission of MCU data-sheet - as we were long taught. Should (instead) advanced, contradictory - and fully INSIDER data be required ... (you may perhaps see our resistance/reluctance.)

Did someone here emit, "Good grief?"

Hello Peter, cb1

Following is the data sheet section from the Transmit and Receive FIFO section of the SSI Chapter...

Otherwise as what Peter mentioned the SSI Master is transmitting the data but the Slave is reading all 0's. To double check the point. If the Master RX pin is made high by the use of Internal Pull Up, it should start receiving all 1's!!!

Regards

Amit

Pardon but that data block you've imported refers to: "Legacy SSI serial conversion" - does it not?  It appears totally silent as regards poster's issue of Bi & QUAD SPI tranfers.

That writing does not (exactly) exude great clarity or understanding - Thomas' "adventure" proves that - does it not?

And - appears now that you (agree) that SSIxDAT0 IS the SSIxTX pin - that NO reversal (from the MCU manual) has occurred!   Can confidence be high in what's what?  (I have tried to assist - to pay attention - yet I'm completely lost!)  (due to the multiple data conflicts - woven now throughout this thread...)

It's understandable that the MCU manual was rushed to meet production - and that this particular feature/function is of minority usage - yet (some) attempt at greater (i.e. some) clarification would seem in order...

Hello cb1

Thoma's post is on Legacy SSI since he is using SSI_FRF_MOTO_MODE_2 which is for legacy mode. Adv/Bi/Quad require to use SSI_FRF_MOTO_MODE_0 and DSS of 8 bits.

Regards
Amit

Hello Amit,

May I offer my "Mea culpa" loudly, unabashedly - here/now? 

You may note that poster Peter John raised the "Bi/Quad SPI" flag - just a few posts displaced from those of Thomas. 

May I plead (just) temporary insanity?  I was sucked in further by (someone's) expression of disbelief - that quad SPI can perform bi-directional transfers - which we know to be true.

Your ability to, "keep these (somewhat) similar posts straight" far exceeds mine...  My intent - as always - was honorable.  (although it, "Did not Work!)

Hello cb1,

In all fairness, that is what I thought as well. So all's well.

Regards
Amit

Hi Amit,

I thank you for that kindness - I cannot recall two posts - arriving so closely together - each targeting (almost) QUAD SPI.
That's my story - (and beg the jury for mercy.)

Thanks Amit. No need to recreate the setup, as your understanding is sufficient to convince me what is wrong.

This was truly a trap, breaking a long standing convention that with SSI, the Tx Master gets connected to the Tx Slave !! now it is back to how UARTs get connected Tx->Rx !

Because we have made a (prototype) PCB already, I've had a thought, it might be quicker for us to use the Bi-SSI (aka BiSS) bidirectional SSI protocol instead and avoid re-wiring things. It means 8 bits are transferred at a time instead of 16. I'll think about it.

I should have read a bit more about the Bi-SSI before titling this thread - my apologies !

cb1- said:

I was sucked in further by (someone's) expression of disbelief - that quad SPI can perform bi-directional transfers - which we know to be true.

cb1, my apologies for misleading you by poorly titling the thread.  Thank you for quickly chiming in and helping me arrive at an answer - albeit one breaking from years of  convention.

regards

Peter

Hello Peter,

Victory declared too early.

a. As I suggested earlier if you can make the master RX Pin as a GPIO Output and drive 1, see that the Slave gets a all 1's pattern and confirm. This way you would not cut-wire the PCB to test.
b. This is clearly a documentation issue to me and I need to add an errata clarifying the pin convention for Slave clearly and master clearly as it does violate the understanding of MOSI and MISO.

Regards
Amit

Amit Ashara said:

Victory declared too early.
a. As I suggested earlier if you can make the master RX Pin as a GPIO Output and drive 1, see that the Slave gets a all 1's pattern and confirm. This way you would not cut-wire the PCB to test.

OK Amit.  I'll be able to perform this test in 2 days' time when I'm back at work.

regards

Peter

Forcing PQ3 (was SSI3XDAT1) to be high resulted in the slave reading all 1's rather than 0's. This confirms the problem was indeed reversed data lines between the slave and master. I blame the datasheet as it wasn't sufficiently clear that legacy SSI needs the master and slave pins swapped contrary to convention.
My colleague even recommended the datasheet contains a diagram showing the master and slave with the Tx and Rx lines joined for legacy SSI.

Thanks again cb1 and Amit for your help on this.

As for our way forward, it seems Bi-SSI will have additional transaction overhead because its bus is max 8 bits wide not 16 bits. furthermore it might take us slightly longer to refactor our code to work with 8 bit data instead of 16 bit compared to re-wiring the lines so it is less risky to swap the lines on the schematic for the non prototype PCB release.

Hello Peter,

Sure. Input accepted for the clarification of the connection

Regards
Amit