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.

TMS320C6748: SPI SOMI output has a negtive pulse on the last bit of one byte, which makes data error sometimes.

Part Number: TMS320C6748
Other Parts Discussed in Thread: OMAP-L138

In my system, I use a MCU to communicate with C6748 throught SPI bus. The MCU is SPI Master, and the C6748 is SPI Slave.

The SPI_CLK is 10MHz, POLARITY = 0 and PHASE = 1.

I use C6748 EDMA to drive the SPI SOMI output.

For test, I let the C6748 to output 0xF1F2F3F4F5F6F7

For SPI_CLK= 4MHz, the read data is always right, which is 0xF1F2F3F4F5F6F7.

For SPI_CLK=10MHz, the read data is sometimes right, but sometimes wrong.

The wrong data is:

Read: 0xF1727374757677

Read: 0xF17273F4757677

Read: 0xF1F273F475F677

Read: 0xF1727374F5F677

.......

At first, I thought maybe the POLARITY and PHASE maybe wrong at the two end. But I've checked that they are alright.

And if the POLARITY and PHASE is wrong, the result should be one bit shift.

But you  can see that, the wrong bit always happens to be the 1st bit of a whole byte!

The waveform tells the truth:

This is a waveform between 0xF3 and 0xF4, there is a negtive pulse between the two bytes.

I think this is why my readata is wrong.

Question: Why there is a negtive pulse between the two bytes?

  • Hi FrankXu,

    Our team will need some time to gather data in the lab. Please allow us a few days and will get back to you.

    BR
    Tsvetolin Shulev
  • We're looking into this.

    Best Regards,
    Yordan
  • Just a guess. Since it works at slower clock speeds, I would guess that at 10Mhz, you are past some of the limits of the SPI Slave timing. See the datasheet. The clock period is probably okay but the inter-word timing might be bad. You might have to configure the MCU to insert delays between words.
  • Hi, Norman Wong,

    Thank you very much for your reply.
    Yes, you are right, inserting delays between words can solve the problem. But there is no settings for delays between words in the MCU, so I can only call SPI_ByteSend() once a time to make delays between each byte. That lows the throughtput a lot.

    Frank
  • I find the the datasheet is not very clear. If I understand correctly, 10Mhz should be okay. But obviously it isn't. Maybe be some TI guys can crunch some numbers for a theoretical SPI slave max clock. What is your core voltage and SYSCLK2? Which port are you using? SPI1 is slightly faster than SPI0. Maybe try a the next clock under 10Mhz.
  • The core voltage is 1.3V and the systemclk is 456MHz. I use SPI0.

    And I think 10MHz is not a very high speed for SPI. But the datasheet doesn't give a max clock.

    I find that, even in 4MHz, there is also a negtive pulse between each byte, which is no normal. Although the read data is right in 4MHz.

    And in 4MHz or in 10MHz, the negtive pulse is always about 20ns.

    And if the SPI is used as MASTER, I find that the SPI CLK has a 20ns gap between each byte.

    In the photo above, the SPI_CLK is 2MHz, the CLK period is 50ns, while the clock period between the two bytes is 70ns. 70ns-50ns=20ns.

    The 20ns gap in MASTER Mode just matches the 20ns negtive pulse in SLAVE MODE. I think maybe there is a relationship between them.

  • At 1.3V and SPI0, the datasheet gives
    tc(SPC)S = 40ns or 3P minimum
    Your clock speed is pretty fast, so I think 3P would be the lesser. Use the greater 40ns. The theoretical maximum clock would then be:
    fc = 1/tc = 1/40ns = 25Mhz
    The above calc does not include the setup time
    tsu(SOMI_SPC)S = 2P
    where 2P = 2 x 1/SYSCLK2. What is your SYSCLK2?

    The negative pulse appears to the idle data level. I think you can define this in the SPI controller registers.

    An aside, in the datasheet for polarity = 0 and phase = 0, SOMI changes on the rising edge, samples on the falling edge, idle clock is low. Your scope capture shows data changes on the falling edge, sample on the rising edge and idle clock is high. Matches the datasheet polarity = 1 and phase = 0. Nothing to do with your problem.

    I cannnot think of anything else. Hopefully the TI guys can comment.
  • Sorry, I made a mistake on writing, the PHASE =1 not 0. I've changed that in the post.
    SOMI changes on the falling edge, samples on the rising edge.
    But that doesn't take effect on the phenomen.You can see that the timing is also OK for that.
    And if it is the timing problem for the PHASE, every bit of the read should be wrong, not only the 1st bit of one byte.

    My PLL0_SYSCLK2 is 228MHz.
  • And one more phenomenon, after the 7 bytes are sent, the SPI_SOMI will keep low for about 800ns, and then rise high slowly.

    I use this method to judge whether it is related to the software:

    In "CommandParsing()" the 7 bytes are set to be sent by the EDMA.

    And the "GPIOPinWrite()" gives the MCU a INT signal to let the MCU SPI MASTER generate the SPI_CLK.

    I add a "while(1)" here to make sure that no other program is running after the EDMA setting. But the waveform is still the same.

    That experiment illustrate that the "800ns low and then rise slowly" phenonmen does not matter with the software.

    Why is that phenonmen? Does that matters with the negtive pulse phenonmen?

  • In slave mode, the SOMI pin is tristated when its CS is deasserted. This is to allow other slaves to take control of the masters input pin. When the pin is tristated, the level is defined by whatever is on the line. In your case, it looks like a weak pullup resistor with a relatively large capacitance.

    More info might be required. Which SPI mode are you using? 3 pin? 4 pin? etc.


    EDIT: Correct punctuation.

  • I use the 4 PIN mode. Yes, the SIMO rising starts with the CS getting high.

    CH1 is CS, CH2 is SOMI

    And If I change to 3PIN mode

    CH1 is SPI_CLK, CH2 is SOMI

    In 3PIN mode, the riising of SOMI disapear. But the negtive pulse at the 1st bit of every byte is still there, and  the read data is still wrong.

  • Okay, I get your point now. Data is changing on the falling edge and stable on the rising edge. That negative pulse starts on the falling edge but disappears some time before the rising edge in some of your scope captures. If your MCU is sampling on the rising edge, the MCU should not sample the negative pulse. In that case, read data should be good. I think at faster SPI clock speeds, you are probably pushing the sampling point into the negative pulse and read data will be corrupted. Admittedly, the negative pulse is odd. Hopefully TI guys can explain it.
  • Yes, that is it.
  • It has been a while since I worked with SPI. The almost random errors reminded me of problems I had with SPI master clock. I found that where the buffer exists matters. If I put the buffer in DRAM, I would get jitters in the clock that I guessed were due to random refresh cycles in the DRAM interfering with the bus access. When I put the buffer in L2 SRAM, the jitter went away. Maybe this is happening to you.
  • Hi Norman Wong,

    Thank you so much!
    I use DSP as Slave, the MCU is SPI Master.
    And if there is jitter in the SPI_CLK, I think all the data bit would be wrong, not only the 1st bit of one byte.
    I think the negtive pulse is odd. Without the negtive pulse, I think everything would be OK.
  • And I tried to change the phase between SPI_CLK and SPI_SOMI a little to solve the problem. In fact, I need to make the SPI_CLK a little delay in the MCU SPI hardware. But in the MCU registers, I can only delay the SPI_SOMI, there is no register settings to delay the SPI_CLK.
    And I have also tried PHASE=0 configuration for DSP and MCU pair, the problem still exist.
    So I think the only way to solve the problem is first to make clear why there is negative pulse. Need for TI's help.
  • Admittely, the SPI clock jitter would symptom of master mode. I think the DRAM refresh would also affect SPI slave mode. Each time the DMA state machine goes off to fetch a byte for tranmission on SOMI, it might be delayed by a DRAM refresh. The DMA refresh occurs on it's own timing. Sometimes it interferes. Sometimes it doesn't. It changes how fast the slave can react to an unchanging clock from the master. Matches the behaviour where not every byte is corrupted with a negative pulse.

    I think most of the timings in the datasheet are constant progagation delays to get a signal through all the silicon. If the negative pulse was due to chip design, I would expect the negative pulse to occur on every byte and every byte would be corrupted. Your original post showed some bytes were occasionally correct even when some bytes were bad.
  • Hi Tsvetolin Shulev,
    Any suggestion about my problem?
    Thank you.
  • Hi Yordan Kovachev,
    Any suggestion about my problem?
    Thank you.
  • In fact, my data is just put on the SHARAM. The EDMA get data from SHARAM and sent to SPI.
    So, I think it doesn't matters with the Memory Read Delay.
  • I assume SHARAM is L3 SRAM that is shared with the ARM on the OMAP-L138. Ideally, L2 SRAM on the DSP would be best for speed but L3 should be okay. Do you have anything else happening on the system. Other DMA? Interrupts? Even memory watch windows in the debugger might barge onto the bus once in while.
  • I'm using C6748. SPI0, EMMC, DDR2, I2C are also used.
    And the same phenonmen happens even in release mode.
  • Hi Cvetolin Shulev-XID,

    Have you seen the same phenonmen in your lab?
    Wishing for your reply.
    Thank you.

    Frank
  • Hi,

    Anybody help me! TI experts, can you give me help?
    Help! Help! .... Help!
  • Hi Norman Wong,

    This post has been created for 30 days. But no replies from TI. Is there any other ways that I can get in touch with TI experts?
    Thank you for your advice.

    Frank
  • You might be able to talk to your TI FAE in your area. My past experience is that the FAE will tell you to post on this forum. My volumes were on lower end of the scale.

    I would suggest you create a stripped down test case that is a complete project and start a new thread. New threads seem to attract more attention. A complete project reduces the amount of work they have to do.

    I think creating a stripped down test case may gave some more hints to the porblem. Remove EMMC, DDR2 and I2C functionality. Remove any timers. If possible put your code and data in DSP L2 memory.
  • Thank you for your advice! I will try that.
  • Hi, have you got any advice? I'v stuck on this problem for 6 weeks. Thank you.
  • Hello FrankXu,

    I am sorry that it has taken this long to receive a response from TI. Are you still stuck on this issue?

    I read through this thread, and I appreciate Norman Wong for offering his support.

    I havent yet found any way to prevent data going low between bytes. But I have some questions for you.

    Q: Does CS go low for each start of word? Can you please include CS in the scope shots along with CLK and Data? The SPI 3-states its output pin when SPIx_SCS[n] is deasserted by the master to avoid conflicting with the active slave device on the bus. These timings may line up with the 20ns you are observing...
    #27 in C6748 datasheet Table 6-74 shows P+17.5ns delay from assertion of CS to SOMI valid
    #28 in C6748 datasheet Table 6-74 shows P+17.5ns delay from deassertion of CS to SOMI hi-Z
    P = period of SYSCLK2, SYSCLK2 = SYSCLK / 2, using 456MHz SYSCLK, P = 4.39ns

    Eyeballing the scope shot, the SOMI data is valid about 30ns before the rising edge that is used to latch data.
    Q: What is the MCU tSU for data valid before rising/latching edge? Why does it latch SOMI so far before the rising edge?
    Q: Where are you probing the signals?
    Q: What is distance between MCU and C6748 SPI SOMI ball? (Propagation delay of data from C6748 to MCU - the MCU probably uses an internal (or pad-loopback) SPI_CLK to latch in SOMI data)

    I notice that the initial bit of the initial byte seems always correct (0xF1)
    Just to confirm, does SOMI become valid 2P before neg edge it "launches" on? - #12 in datasheet Fig 6-39
    Maybe we should treat the MSB of each subsequent byte as a subsequent bit (so Timing #13 applies)
    The SOMI MSB does appear to have a output delay from falling edge to rising edge
    #13 in datasheet Table 6-69 states that the output delay after the transmit (negative) edge is max 17ns
    #14 also states that the data hold time from the previous rising edge is at minimum one half SPI clock cycle minus 6ns. During this time, the SOMI data is unknown and must not be latched.
    These timings are close to the 20ns you measured where SOMI is driven low for some MSBs.
    Q: Does the MCU have a similar feature to insert delays between each word? Like the WDELAY field in the C6748 SPIFMTn register?

    Regards,
    Mark
  • Hi Mark,

    Thank you very much for reply!
    I've started a new post, and I think I have found the cause of the problem and the solution:
    e2e.ti.com/.../2507332
    I think: When PHASE=1, the C6748 SPI peripherial has a hardware bug, which makes the SOMI/MOSI has a negtive pulse. And if the SPI_CLK frequency is high, the negtive pulse will makes the data wrong on the 1st bit of every byte.

    Regards,

    Frank