Can SSI2 port of TM4C1294 QSSI work as slave in QUAD or BI -mode ?

Hi Amit, as I continue to insist, IF Forum get split from ROOT to peripheral and specific sub forum to address these problem is more simple to collect all data and see what happen on that service than trying to dive in a biggest inform mass of intermixed data. Preselected data can be read and see from one has that specific trouble.

 TIVA is too complex to leave all in one container.

Thomas Heinke said:

Got SSI2 of the TM4C1294 working in LEGACY mode as master and slave and in QUAD_WRITE mode as master

Thomas - we cannot tell if you succeeded w/QUAD_READ mode as master - might you explain?

Like you - our small group requires faster data transfer - only possible via quad.  

Perhaps you can further detail "when/where" your effort fails when (as Slave) in "Quad_Read" mode?  We've used another's M4 - and that has worked for us.  Sometimes - the speed of (this vendor's) SPI must be dialed (far) down when in Slave mode.  (at least that was true historically - we've not used 129 devices...)

Follows a "swag" - more than once we've found that the main Peripheral Port is, "most extensively tested/verified" - thus I suggest you try w/SSI1.  (we've noted this @ several ARM MCU vendors - not just here...)  Again - your report of, "Failure when in Slave mode" deserves a close read of SSI section w/in MCU manual - to see if SSI data rates must be "dialed down."

Thomas Heinke said:

I tried only QUAD_WRITE in master mode and succeeded, haven't tried QUAD_READ...

Your use of the FPGA justifies - yet we're mystified as to the (effective) value of Quad_WRITE, only.  (in our experience - far more often we require Quad_READ to "pull" multiple font & image data from "massive" quad-based SPI storage devices.  We dislike this vendor's use of MCU code space for font/image storage!)

To be clear - clock speed you dialed down was for SPI only - was that the case?  And - that clock must be from your external SPI device Master - not this MCU.  

Thanks your quick, detailed response.   Salute what you're doing - quad SPI storage devices (and others) offer great speed-up over single bit parts - we'll (never) go back!

Hello Amit,

I think your "basic rule" applies only to the master mode. One needs to "Put" to start the clock and a frame sync. In slave mode, where external logic is producing the clock and the frame sync, it doesn't seem necessary to "Put" before you can "Get".

When I used the "Legacy slave mode" (and had the FPGA generating the clock an frame sync) I got data just with "Get".

I'll try to move SSIAdvModeSet after SSIEnable tomorrow, it's a little late to do work today.

Thomas

Those settings appear (from my "unused that device" perspective) "Good for Gov't Work." We note that few (other) ARM MCUs enforce so potent a speed restriction when operating in Slave SPI modes.

While awaiting "officialdom" you may wish to consider "bit bang" to manage (only) that read of the quad data. (we did such w/another's MCU - and then chose newer/improved (and less costly) device - which worked flawlessly - both master & slave!

BTW - I agree w/you - vendor here is buried in (endless) repeat neophyte explanations - sometimes "dulling" analysis. Just as you assert - that external clock dictates SPI data - NO "Put" should be required when receiving data as SPI Slave. Do consider a bit-banged port read - not that hard - and frees you from (present & future) gremlins - apparently lurking your MCU...

It's quite clear that the absence of any "reasonable" examples for both Bi & Quad SPI Peripheral management causes such concerns.

As the Master device - not the (slaved) MCU - in poster's (read Quad SPI data) case - generates the SPI clocks - the use of "Put" prior to "Get" (still) seems of little merit...  (that was poster's {yet unanswered} question - we believe...)

Amit and cb1_mobile,

- moving SSIAdvModeSet after SSIEnable doesn't help

- bit banging will not work for me, the data input needs to happen in the background via DMA (haven't worked on this topic yet)

- making an output before input WORKS (thanks to Amit for pointing into this direction), a single output with bits[15:13] properly set seems sufficient, it doesn't need to be done for every byte

- in order to configure PD7 as SSI2XDAT2 it needs to be unlocked first

QUAD_READ in slave mode works for me with the attached program fragment - have to work now on the DMA stuff for the complete solution.

Thomas

SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI2);

SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);

HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;
HWREG(GPIO_PORTD_BASE + GPIO_O_CR) = 0x80;

GPIOPinConfigure(GPIO_PD3_SSI2CLK);
GPIOPinConfigure(GPIO_PD2_SSI2FSS);
GPIOPinConfigure(GPIO_PD0_SSI2XDAT1);
GPIOPinConfigure(GPIO_PD1_SSI2XDAT0);
GPIOPinConfigure(GPIO_PD6_SSI2XDAT3);
GPIOPinConfigure(GPIO_PD7_SSI2XDAT2);

GPIOPinTypeSSI(GPIO_PORTD_BASE, GPIO_PIN_7 | GPIO_PIN_6 | GPIO_PIN_3 | GPIO_PIN_2 | GPIO_PIN_1 | GPIO_PIN_0);
SSIConfigSetExpClk(SSI2_BASE, SysCtlClockGet(), SSI_FRF_MOTO_MODE_0, SSI_MODE_SLAVE, 1000000, 8);
SSIEnable(SSI2_BASE);
SSIAdvModeSet(SSI2_BASE, SSI_ADV_MODE_QUAD_READ);

SSIDataPutNonBlocking(SSI2_BASE, 0x4000);

while(1)
{
	for(ui32Index = 0; ui32Index < NUM_SSI_DATA; ui32Index++)
	{
		SSIDataGet(SSI2_BASE, &pui32DataRx[ui32Index]);
		pui32DataRx[ui32Index] &= 0xFF;
	}
}

Amit Ashara said:

Even a dummy write of 0x00

Perhaps - but one must remain mindful that MCU (here) is SPI slave - and it's emission of any data to the SPI master - must comply w/any/all master's data requirements...  Thus (some) care must be employed in the selection of the "dummy write."

We note that this dummy write seems not to be a "universal requirement" (by other M4 MCUs - equipped w/Quad SPI capability...)  Clocks from the master (alone) fully enable SPI data reception by those MCUs...

Hello Amit,

You are right, a dummy write of 0x00 works as well as the 0x4000. I tried 0x4000 because of this statement from the datasheet, that you had quoted too.

"The mode of operation bits [15:13] in the TX

FIFO are used by the QSSI module for configuring the data on the proper pins."

Re. cb1's concern: The Quad mode works only half-duplex and it is set into READ-mode. In addition my FPGA will never receive any data via SPI, so a dummy write cannot do any harm. For a bi-directional connection dummy data in the stream can be a problem - fortunately not in this particular application.

I guess, we can close this discussion.

Thomas

Amit Ashara said:

...cb1: How SSI is seen as an interface in products and how the module must have been done (which would have saved you the issue of doing a dummy write).  

You are correct, Sir.  While you earn kudos for satisfying Thomas - the "non-standard" interface mechanism may very well "impede" the added speed which is - after all - the "raison d'etre" for QUAD SPI.

One hopes that (forced) dummy write is "temporary" and that more normal/customary QUAD SPI transfer protocols may be accommodated...

Doubtful that "too many" will find this post - extract this (very insider/extra dummy transfer write) under QUAD_SPI_READ - and avoid Thomas' (delayed/pained) fate...