TMS570LC4357: SPI legacy mode no CS just CLK and DATA slave speed limitation to 11 Mbps effective communication rate on a 75 MHz VCLK.

Hi Rene,

1. Is the SPI clock the specified rate: 15Mbps or 25 mbps?

2. The Wdelay is the delay between two transmissions: (WDELAY + 2) × VCLK

3. What are C2TDELAY and T2CDELAY in your setting? the delay between CS low to SPI clock edge is (C2TDELAY + 2) × VCLK, and (T2CDELAY + 1) × VCLK

Rene Lebel said:

The 16 bit character value sent is 0x2222 and I am getting: 8888, 1111, 9111, 4444 when playing with all combinations of polarity and phase.

Please increase the C2TDELAY

1) Either speed are supported by our hardware.  Let's compute any setting based on 25 Mbps bit rate.

2) yes (WDEL)

3) Their default values. I am  not using C2TDELAY/T2CDELAY since CS related and I am not using any CS. 

Should I still configure the C2TDELAY anyway?

In master mode, nCS is used to select a slave. In slave mode, nCS is used to enable/disable the transfer. If only one slave, you don't have to use nCS.

If SPI=15MHz, transmitting 28 16-bit words will take about 41us:

(28-1)*Wdelay + 28*16 periods + 28*CS delay (3 vclks)

As I have suggested, please use 25 MHz in your examples.

Why using CS delay in your formula since not using any nCS line?

As an answer to my former questions, please suggest a values for: C2TDELAY, T2CDELAY, WDEL with your timing computations.

Thanks.

C2TDELAY, T2CDELAY are inserted even the chip select pin is not used. Can you please post your waveform of 2 16-bit words transmission?

Waiting for internal support to probe these signal. 

Meanwhile can you explain why the spec days there is 8KB of DCAN2 RAM and using DRA bit I can only access 4KB of it? FF1C1000 and above can't be initialized.

To provide a waveform, I intend to not use WDEL and only go by C2TDELAY and T2CDELAY.  Please provide a value for C2TDELAY and T2CDELAY that I will use for the test and when possible I will provide a waveform.

Putting WDEL=0, C2TDELAY & T2CDELAY = 0x0A  makes the first 28 character DMA based transfer very fast and buffer content and CRC checked OK.

The second 28 character DMA transfer, it doesn't complete at BTC interrupt and I am missing 1 character in my buffer.  It is missing the second character. I was expecting 0x5609 0x0A0B 0x0C0D.... and I am getting 0x5609 0x0C0D 0x0E0F ...

I am using bypass mode and giving RX channel hi priority. I am keeping SPI request connected to DMA.  I am keeping DMA request mapped to SPI.  I am simply disabling the hardware request.  I am starting DMA via the HWCHENAS register.

With large WDEL I wasn't loosing any data by the total transfer time was much larger.

I will try to get a scope snapshot of it.

Any idea why I would be missing the second character?

I re-introduced WDEL value and it will only work with WDELAY = 38 and above.

That is with disable or enable of the C2T and T2C delays.

So it work at high speed but only with WDELAY = 38 I am not losing the second character.

The picture above confirms missing transmission of second character.  So that explain why not received.

What can cause loss of this character?  Extra request pulse from SPI lost by DMA, lost request from SPI because DMA not ready?.

After this exchange a single character is sent by SPI2 and received by SPI3 in interrupt mode.

Then DMA is used to send and received the same data at the same time on each board using the link.

No FIFO, using BYPASS and priority is given to SPI3 on reception.  SPI2 TX is on DMA channel 3, SPI3 RX is on DMA channel 2.

The SPI on TMS570LC43x can run with up to 25 MHz. The delay time between individual frames (WDELAY) is necessary to give the SPI or MibSPI slave enough time to copy the received data from the shift register to the SPIBUF or MibSPI RAM and vice versa, and also to give the DMA time to copy the data from the SPIBUF or the MibSPI RAM to the SRAM. If the timing is too aggressive, data loss would be the consequence.

Agree, but I am not loosing data for the first transmission.  So the TMS is doing its job.  It is the second DMA based transfer that miss sending the second character only.  This is because there is an extra DMA REQ sent in the DMA pipe.  The first one is extra.  The second one, a good one from SPI, writes 0x0A0B and if no large WDEL delay, it gets overwritten by the third one, from SPI, ending in writing 0x0B0C over 0x0A0B.  So I may have to flush an extra DMA REQ.  Why is my DMAREVID shows: 0x4A0D3802 instead of 0x4A0D0003 as in the spec, p. 726?

After first DMA xmit at BTC the PEND (p. 725) was suppose to cleared.  It isn't. Yet I do get the BTC interrupt, the data is sent (confirmed received at the other end) and the read of the BTCAOFFSET register does clear the pending interrupt.  Why is the PEND bit still set?