SPI slave is missing spi clocks?

Hi Morizzo,

Thanks for your post.

Usually, the SPI master can monitor the slave SPIx_ENA activity to detect any condition to happen a desynchronization event. Some possible conditions are:

1. Master or slave device would have been reset during a transmission.

2. Software reset of the SPI module during Tx. would have been asserted.

3. Incorrect SPI pin configuration which would cause the SPIx_ENA pin to behave incorrectly.

4 Signal integrity problem will cause additional clocks to be recognized by the slave.

With respect to above possilble conditons, the master can detect two desynchronization error conditions on the SPIx_ENA pin:

1. Slave deasserts SPIx_ENA after a transmission has begun, but before it completes.

2. Slave fails to deassert SPIx_ENA within a certain time period after the completion of the last bit of the transmission.

To spot out second error condition, the SPI module which includes an eight-bit counter with a timeout value that can be configured through the T2EDELAY field in the SPI delay register (SPIDELAY).

If any of the above desynchronization events needs to be detected, you should possibly enable the DESYNC bit in the SPI receive buffer register (SPIBUF) and the DESYNCFLG bit in the SPI flag register (SPIFLG) which needs to be set to assert a desynchronization error interrupt.

I would recommend you to set the above register bits to assert any desynchronization error interrupts for your incomplete EDMA transfer case. Also configure the T2EDELAY field in the SPI delay register to check for error condition 2.

For more details, please refer section 30.2.14.3 in the omapl138 TRM as below:

http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf

Kindly try out all the possible usecases to spot out the desynchronization error conditions, if any.

Thanks & regards,

Sivaraj K

Hi Sivaraj,

Thank you for your quick reply and listing up the conditions I should look into.

I forgot to write an important point in the previous post.

I am using 3-pin spi slave mode. So I suppose that condition on SPIx_ENA / SPIx_SCSn pins does not matter. Is this correct?

Here is a pic of SPI registers just after this problem occurs:

It would be helpful if any comments on the register settings.

I think that signal integrity is most possible cause in this case. But I have not seen any fault in signal swinging level, slew rate and rising/falling edge counts so far. I believe that the SPI master drives spi clock correctly in its signal quality and its count. Problem should be in SPI slave side.

Anyway, I am going to check carefully each of what you pointed out and I will post again if I find something new.

Thanks,

Morzzo

Hi Sivaraj and all,

I am still working on the issue in this post.

I have a hypothetical idea about how the issue happens in OMAP-L138.

Could anyone, hopefully TI engineer, please verify it from internal side of OMAP-L138?

My hypothesis is:

1.  EDMA transfer may not be in time. Remember that OMAP-L138 is SPI slave and SPI master keeps sending data even if receive data in SPI register is not cleared. The interval of EDMA request for SPI transfer is about 1usec @ 8Mbps with 8bit per word.
   
   
2. Then, SPI peripheral will ignore incoming clock/data by bit, not by word, when received data is still in the rx register due to delayed EDMA transfer.
   
   
3. When EDMA transfer finishes and clears rx register, then SPI peripheral starts receiving incoming data/clocks again despite word boundary.
   
   
4. In result, following data is out of word boundary.

If this is true, I think that OMAP-L138 is not suitable for receiving SPI stream as SPI slave.

And how can I boost up response of EDMA request? I have already tried to change MSTPRIx registers to put EDMA3_0_TC0 higher priority but it does not improve very much.

Can I get a internal timing chart of EDMA controller in OMAP-L138?

Thanks in advance,

Morizzo

I am using TMS3206748 in SPI slave mode.

I can run at 5MHz successfully. At 10MHz, randomly gio_submit() returns IOM_ENOPACKETS and also, sometimes callback function is not called.

I checked out SPI slave specs and I should be able to run at 15MHz. 

status = GIO_submit(spiHandle, IOM_READ,  &spi_dataparam, &len, &SpiCallbackFunction);

oGPIO.GPIO_SetPinVal(DSP_IMX6_GPIO3, GPIO_PIN_LOW);//tell master to send clocks

status = SEM_pend(&SEM_SPI0_Done, SYS_FOREVER); // callback function posts semaphore

What I could be doing wrong or are there any limitations?

Thanks & regards

Manish