Continuous SPI Clock Between Words

Hello Glenn,

Would we be correct to assume you tried all the Phase and Polarity settings for all 4 SPI modes as in section 8.2.2.2.5 and none of those produced a continuous SPI clock?

Thanks,

greenja said:

Would we be correct to assume you tried all the Phase and Polarity settings for all 4 SPI modes as in section 8.2.2.2.5 and none of those produced a continuous SPI clock?

Yes, I have tried all 4 combinations and none produced a continuous clock.

Not being able to make this function will mean I cannot use the CC3200, so I am hoping I can somehow create a continuous clock. Otherwise it is the CC3100 + Tiva C, which makes things more expensive, also the CC3200 has more ram, which I would have liked to have had.

Glenn.

Does the same thing happen when you use 16 or 32 bit data lengths?

Same issue occurs, except the extra cycle occurs after each 16 bit or 32 bit word.

I need to send a large stream of data many 100s or 1000s of bytes long.

Glenn.

Interesting.  Well I haven't played with the SPI enough to really know what the problem is.  It does look like the clock is being held high at the end of the last bit until the new data arrives.

Here are a couple of suggestions:

1. Try to configure the pin manually to weak pulldown or,
2. Place a 20K pull down resistors on the SPI clock pin

Also, what is the SPIEN pin doing after the first data byte is sent?

Thanks,

I have tried all different combinations of SPIEN, the Pulldown doesn't solve the issue. I couldn't find any registers which I could use to configure the clock.

I received this from the TI guys on the TI-RTOS forum:-

"The SPI peripherals on those 2 devices are different. On the TivaC part, the peripheral strobes the hardware chip select pin between SPI frames (during the gap). As you mentioned, to change the gap behavior, you need to change the polarity and phase option for the TivaC device."

So this looks like it needs someone with deep knowledge of the SPI clock hardware to see if what I need is possible.

Glenn.

Hi Glenn,

You can use "turbo mode" to reduce the idle cycles between transfer of successive words. You can't totally eliminate it. Below are my observations with and without "turbo mode" for the SPI configuration of 20 MHz, DMA and 8 bit Word Length.

1. Normal mode : 4 Idle cycles between transfer of two words

2. Turbo mode : 1.5 Idle cycles between transfer of two words

Enabling Turbo mode :

Parameter ulConfig should have "SPI_TURBO_MODE_ON" when SPIConfigSetExpClk is invoked. Please note that there is issue regarding enable of "turbo mode" in the SPIConfigSetExpClk API. We will fix this in the next SDK release. Please make the below change in the SPIConfigSetExpClk API to fix the issue.

Fix in SPIConfigSetExpClk for enabling turbo mode : SDK version - 0.5.2, File - driverlib\spi.c, Line no. - 821 

Existing : ulSubMode) | (ulConfig & 0x0000FFFF));

Fix : ulSubMode) | (ulConfig & 0x0008FFFF));

Please see if this helps.

Thanks and Regards,

Siddaram

Hi Siddaram,

Thanks for looking into this. I have tried Turbo Mode, and unfortunately this still does not suit my purposes.

I am using the SPI MOSI and Clock combined with a XOR IC to create a Manchester encoded signal, the delay causes all my bits to shift and hence the device receiving the Manchester encoding fail to decode correctly, which is a real issue.

I really hope there is something I can do, as it is disappointing that I cannot use the CC3200 because of a slightly different SPI Clock to the Tiva C.

I cannot even think of any work arounds to this issue. Possibly UART, if I use 2 bits to represent every 1 bit, but at 500Mhz (actually 1GHz due to the doubling of bits) this is likely not possible with UART. I2C will not work due to its protocol overhead.

Any suggestions appreciated.

Glenn.

Hi Greenja,

Thanks for the suggestions, I will look into these as a possible work around. 

Glenn