TMS570LC4357: SPI delay in between packets

Part Number: TMS570LC4357

Hello 

I have setup a baremetal driver for the qspi MIBSPI5 of the tms570 chip. However, you will notice there is a delay in between each 16 bit packets, as seen in the below screenshot of my logic analyser. The delay in between each clock burst is of about 100ns for a 25MHz clock. i send a burst of 128 packets of 16 bits on the four data lines.
The WDEL and DFSEL bits of every buffer in the txram of mibspi5 is set to 0, i have checked directly in the ram. The WDELAY bits 24 to 31 of the SPIFMT0 register are set to 0, and all bits of the SPIDELAY register are 0,i have validated directly in the registers using my debugger. What am I missing, why is this delay present? I would expect that i could send data continuously without a pause in the clk line?

0. CLK
1. CS (not functionnal, will solve seperately)

2-5. mosi 0-3



Thank you very much for any help you can provide!

Sean

  • 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?

  • 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!

  • Hi Sean,

    I noticed the delay between each transfer. The delay is about 6 VCLK cycles.

    If either a CPU or a DMA controller is accessing the Multibuffer RAM when a buffer transfer is completed and the Sequencer tries to write the received data to RXRAM after the completion of a transfer, then due the Bus Arbitration logic, there can be several VCLK cycles of delay before the Sequencer gets the bus. 

  • 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!