TMS570LC4357: SPI delay in between packets

Hi Sean,

It looks like the parallel mode is used. The delay between two transmissions is T2CDelay + C2TDelay = 3*VCLK periods. What is the VCLK in your setup? 

My VLCK is 75MHz, and both T2CDelay and C2TDelay in register SPIDELAY are 0

Also, in between all transmission CSHOLD is set to 1 except the last transmission.

Hello, Would you have any more information on the cause of the delay, knowing that vclk is 75MHz? i would only expect one clock cycle as a delay in between bursts. 

Thank you!

For regular SPI transmission, there should be no delay between the 2 transmission if CSHOLD is set to 1 and WDEL=0.

The picture below shows 2 words transfer using SPI3. The word length=16-bit, and CSHOLD is set.

Hello QJ,

Thanks for the answer! Unfortunately this does not solve my issue though, as I already have WDEL and CSHOLD properly configured. This is why it is such a mystery to me that there is a delay. 

The following values I have read directly in ram or in their respective registers, so i know they are correct:

WDEL = 0
CSHOLD = 1 
C2TDELAY  = 0
T2CDELAY = 0
WDELAY = 0
i have also since i posted this fixed the CS, which works well. I can see on the CS line that it remains low for the entire transmission of 128 packets, as expected.

This is working in parallel QSPI mind you, not in regular SPI. Is there some difference in delay between both of them? I would expect that there isnt, as that would be described in the TRM. 

What information can I provide you that would help explain this behavior? 

Thanks again, 

Sean

Also i can see that you are using an spi clk at 1MHz in your oscilloscope diagram, using my logic analyser at 1MHz i can see that there is still a delay of about 100ns in between burst in mibspi of 100ns. Try setting the prescaler to 2 for a 25MHz spi clock to see if you can reproduce the delay?

sean beitz said:

This is working in parallel QSPI mind you, not in regular SPI.

Do you mean there is no delay between the two word transmissions in parallel mode?

I will do a test with faster SPI speed (25Mhz). The delay of 100ns may be caused by executing the code in while(blocksize != 0U) loop in the API.

In multi-buffered mode (MibSPI), multiple transfers are queued up before starting transfer, so there is no latency between transfers.

Sorry i meant i was configured in parallel spi not in single spi for the above test, even though this delay is always present in single or parallel mode. I am also not using the API, but a baremetal driver i wrote myself. The code waits till the whole txram is filled before sending it by enabling TGENA, so there are no possibilities of "code" delays. I can even pause the debugger right before enabling TGENA to make sure that the TXRAM is full of the values i wanted and the delay will still be present. (just to make sure i also tested this without a debugger connected, and the delay is also present)

Also, even if i vary the frequency of VCLK to something smaller than 75 MHz, the delay always seems to be proportionately the same, about 8 periods of VCLK. 

I have included here an image of the state of all the registers and the TXRAM, just in case you see something i dont.

Thanks again,

Sean

Hi Sean,

Thanks for providing so detailed information. I am busy today, and will run a test by tomorrow. Sorry for the delay.

Ok thanks for the help!

So if i understand properly, this is a limitation of the sequencer, and this delay cannot be reduced in any way unless we get a higher value on VCLK? If this is the case, i will close this ticket as solved.

This is not explained in the reference manual, as far as i can tell. There is only a little blurb about bus arbitration on page 1503. If it indeed isn't explained, i recommend it be included in the next revision of the reference manual either verbally or with a timing diagram. 

Thanks a lot for the help, you've been great!