• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 857 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

TMS570LC4357: SPI Clock Questions

TMS570LC4357: TMS 570 MIBSPI slave clock timing and data mismatch

Sree P
Prodigy 70 points
Part Number: TMS570LC4357

Hey Team,

I've asked a question regarding the TMS570 mibspi in slave mode here. The following query can be considered a follow up on that question. We have been able to set up and test the following (This is setup to test the MIBSPI.)- 

  1. TMS570 chip as slave with external master and external clock (which is also a TMS dev kti Hercules xl-570LC4357). 
  2. External clock for the slave is currently coming from the master tms 570 but on the actual board is a free running clock coming from a dsp chip.
  3. 4 pin mode (CS, MOSI MISO, CLK) but in out case we only have data transmission from master -> slave. so we only connect MOSI pin and leave MISO floating.

With the above mentioned setup we are able to send data (uint16 {1,2,3,4,5,6,7,8}) over MIBSPI at 6.75 Mhz and see the following behavior.

  1. We send this data continuously from the master in a while loop.
  2. For most of the times, we are able to see the same data on the slave.
  3. Some of the times we are only seeing zeros upon copying rx data. This is after checking the RXEMPTY bit in the SPI receive register buffer.

Seeing this behavior leads me to believe that the sampling is not happening exactly when it should leading to the salve believing that it sees some data but it actually is just sampling 0's. Clock phase and polarity on both ends is 0.

When we increase the frequency to 12.5 Mhz, we don't see the exact data at all and see data bit shifted to the left ({0x10,0x200,0x300,..}) or see a list of 0's upon reading the rx buffer. This is only resolved by placing a considerable amount of delay between two subsequent transfers. 

On our board the master device is a dsp chip that is sending data in the spi format and is outputting a free running clock as spi clock and has active low config for chip select whenever sending data. In this case we are unable to suspend the free running clock in the spi clock line. The delay between subsequent CS lows is ~25 microseconds. Our VCLK is set to 75 Mhz. We see the above mentioned issue of multiple 0's or bit-shifts here as well.

Is this still acceptable behavior from the tms side since it should ideally only look into the clock upon when CS goes low ? If it is then how do we resolve the issue of bit shifts and incorrect sampling. Our requirement is to run the mibspi clock at 25.576 Mhz and send data on the SPI bus at that rate. the below shown image is what the actual spi transaction looks like. 



Thanks 
Sree

  • 0
    TI__Guru**** 193206 points

    Hi Sree,

    The SPI Input data is latched on the clock falling edge. If there is an extra clock pulse between CS falling edge (CS becomes LOW) and 1st data bit (MOSI), the received data is 1-bit shift of the transmitted data. 

    How do sync your MOSI data to the free-running clock signal and meet the data setup and hold time defined in datasheet (7.12)?

  • 0 in reply to QJ Wang
    Prodigy 70 points

    Hey QJ,

    For the initial statement if we send (0x01,0x00) another falling edge of a clock would give us (0x00,0x80). we see the shift usually in the opposite direction which is (0x02, 0x40) etc. 

    Sync of MOSI and free running clock happens since they're generated by the same DSP serial output unit which has its own clock generator and that port would output the data based on clock edges as defined in its configuration. The setup and hold times are matching as shown in the diagram below since this is a TMS to TMS spi master to slave communication at 12.5 Mhz and replicate it onto our board. We see the shifts happening and 0's being read even in the TMS <-> TMS SPI communication.

  • 0 in reply to Sree P
    Prodigy 70 points

    Just to add on this , for our onboard setup the clock waveform looks like as shown below which is still being sampled on the falling edge of the clock. The data we're sending is (0x00 0x01 0x00 0x01 0x00 0x01 0x00 0x01) and the data we're receiving is shown below of different frequencies, gdb output for a sequence of what we're receving and the spi buf receive register value in reception of buffer..

    For 12.5 Mhz -

    $3570 = {0x0, 0x2, 0x0, 0x8, 0x0, 0x20, 0x0, 0x80}
    $3571 = 0x103e0100
    $3572 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
    $3573 = 0x103e0100
    $3574 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
    $3575 = 0x103e0100
    $3576 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
    $3577 = 0x103e0100
    $3578 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
    $3579 = 0x803e0000
    $3580 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
    $3581 = 0x103e0100
    $3582 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
    $3583 = 0x103e0100
    $3584 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
    $3585 = 0x103e0080
    $3586 = {0x0, 0x4, 0x0, 0x10, 0x0, 0x40, 0x0, 0x100}
    $3587 = 0x803e0000

    For 6.25 Mhz - 

    $3598 = {0x0, 0x1, 0x0, 0x1, 0x0, 0x1, 0x0, 0x1}
    $3599 = 0x903e0001
    $3600 = {0x0, 0x1, 0x0, 0x1, 0x0, 0x1, 0x0, 0x1}
    $3601 = 0x903e0000
    $3602 = {0x0, 0x1, 0x0, 0x1, 0x0, 0x1, 0x0, 0x1}
    $3603 = 0x103e0001
    $3604 = {0x0, 0x1, 0x0, 0x1, 0x0, 0x1, 0x0, 0x1}
    $3605 = 0x103e0001
    $3606 = {0x0, 0x1, 0x0, 0x1, 0x0, 0x1, 0x0, 0x1}
    $3607 = 0x103e0001
    $3608 = {0x0, 0x1, 0x0, 0x1, 0x0, 0x1, 0x0, 0x1}
    $3609 = 0x103e0001
    $3610 = {0x0, 0x1, 0x0, 0x1, 0x0, 0x1, 0x0, 0x1}
    $3611 = 0x103e0001
    $3612 = {0x0, 0x1, 0x0, 0x1, 0x0, 0x1, 0x0, 0x1}

  • 0 in reply to Sree P
    TI__Guru**** 193206 points

    The SPI module on TMS570 devices generates SPI clock only when transmitting data, and it doesn't support free-running SPI clock. If MibSPI mode is used as slave, the SPI master has to wait 6 VCLK before sending the clock to begin the transaction. Between two transfers, there are a delay of 2 VCLK cycles. 

    if the SPI clock is much slower compared to VCLK, it may work since the delay is small relative to period of SPI clock. 

    The maximum SPI clock supported is 25MHz. 

  • 0 in reply to QJ Wang
    Prodigy 70 points

    Hey QJ,

    For this delay i have 2 questions - 

    1. 6 VCLK cycle delay - is this between the CS going low and actually data starting. Can the clock be running in this duration and it would be ignored ?
    2. 2 VCLK cycle is between each SPI transaction regardless of the transfer group size we declare or is it between each data in the buffer ?
  • 0 in reply to Sree P
    Prodigy 70 points

    Also when I expect to receive (0x00FF, 0x00FF, 0x00FF, 0x00FF, 0x00FF, 0x00FF, 0x00FF, 0x00FF)I receive some data as 

    $2144 = {0xff0, 0xff00, 0x3f000, 0x3f0000, 0x3fc0000, 0x3fc00000, 0xfc00000f, 0xf0000}
    $2145 = 0x813e000f (SPIBUF)

    since the spibuf value is 0x813e000f and the 24th bit (DLNERR) is set to 1, would it also mean that the spi module would know if it misses a clock. The TRM states 

    Data-Length Error in Slave Mode: During a transfer, if the SPI detects a de-assertion of the SPICS pin before its character length counter overflows, then an error flag is set to indicate a data-length error. This situation can arise If the slave SPI misses one or more SPICLK pulses from the master. This error in slave mode implies that both the transmitted and received data were not complete.

  • 0 in reply to Sree P
    TI__Guru**** 193206 points
    Sree P said:
    6 VCLK cycle delay - is this between the CS going low and actually data starting. Can the clock be running in this duration and it would be ignored ?

    This is the delay between CS falling edge and rising edge of the 1st clock signal. Between those two signal edges, there should be no SPI clock signals.

    Sree P said:
    2 VCLK cycle is between each SPI transaction regardless of the transfer group size we declare or is it between each data in the buffer ?

    It is the minimum delay between two transfers.

  • 0 in reply to QJ Wang
    Prodigy 70 points

    Just to confirm, When you say minimum delay between two transfers , is that minimum delay between 2 16 bit data being received since the shift register of the spi is 16 bit ? 

  • 0 in reply to Sree P
    TI__Guru**** 193206 points

    Yes, there is 2 VCLK cycles delay between two transfers.

  • 0 in reply to QJ Wang
    Prodigy 70 points

    Hey QJ , I have a follow-up question regarding this. For example, I have mibspi5 configured as slave and I have the following data coming in on the mentioned lines. I have it configured in MIBSPIP mode with 2 data lines using the pmode function in mibspi.c and running at around 6.25Mhz clk rate  -

    I have 
    SIMO 0 - 0x00 0x05 0x00 0x05 0x00 0x05 0x00 0x05

    SIMO 1 - 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00 

    I'm seeing data in my recv arr as follows - 

    recv unsigned short[16] 

    [0] unsigned short 0xFF00 (Hex) 0x08000FB8
    [1] unsigned short 0xFF00 (Hex) 0x08000FBA
    [2] unsigned short 0xFF00 (Hex) 0x08000FBC
    [3] unsigned short 0xFF05 (Hex) 0x08000FBE
    [4] unsigned short 0xFF00 (Hex) 0x08000FC0
    [5] unsigned short 0xFF00 (Hex) 0x08000FC2
    [6] unsigned short 0xFF00 (Hex) 0x08000FC4
    [7] unsigned short 0xFE05 (Hex) 0x08000FC6
    [8] unsigned short 0x0000 (Hex) 0x08000FC8
    [9] unsigned short 0x0000 (Hex) 0x08000FCA
    [10] unsigned short 0x0000 (Hex) 0x08000FCC
    [11] unsigned short 0x0005 (Hex) 0x08000FCE
    [12] unsigned short 0x0000 (Hex) 0x08000FD0
    [13] unsigned short 0x0000 (Hex) 0x08000FD2
    [14] unsigned short 0x0000 (Hex) 0x08000FD4
    [15] unsigned short 0x0105 (Hex) 0x08000FD6

    Can you help me understand why the data is being shifted in as such and what does the expected data look like ?

  • 0 in reply to Sree P
    TI__Guru**** 193206 points

    If 2-pin using parallel mode, the received data[15:8] is SIMO[1] and data[7:0] is SIMO[0] 

    The data in MibSPI RAM should be 0xFF00, 0x FF05, 0xFF00, 0xFF05, ....