• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 337 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2642R: SSI Minimum Required MOSI Hold Time in Peripheral Mode

Stuart Baker
Genius 10620 points
Part Number: CC2642R

Tool/software:

I'm working with a customer that is using an NXP K24 MCU as a SPI controller to our CC2642R operating in SPI peripheral mode. The SPI controller on the NXP device is demonstrating a rather short hold time of the MOSI data on the last bit shifted in a given byte. This can be seen in the following logic analyzer plot:

It is acknowledged that the sample rate for the logic analyzer is a bit low, and thus the edges, and subsequent 62ns measurement may not be exact in this plot. I believe the exact number to be closer to ~80ns of hold time in reality.

The customer is finding that the last bit of an SSI byte transaction is often getting corrupted on the CC2642R peripheral side. They found a setting in the NXP SPI controller that appears to have the effect of extending the MOSI hold time at the end of each byte to >100us. When they enable this setting, it appears to resolve the last bit corruption, and the issue is no longer reproducible.

The question being asked is what is the minimum hold time required on the MOSI line in SSI peripheral mode for the CC2642R. They need to confirm that this fix provides sufficient margin to have confidence in the solution. The datasheet does not contain this information, and the closest thing we could find to an answer is in the following E2E thread, which is not a definitive answer.

e2e.ti.com/.../cc2642r-q1-timing-parameters---cc2642-s-ssi

What is the minimum required MOSI hold time for the SSI in peripheral mode on the CC2642?

Thanks,

Stuart

  • 0
    TI__Genius 10620 points

    To confirm some additional system parameters, customer is using the TI SPI DMA driver, in DMA mode, with SDK version 5.10.00.48. The SPI clock frequency is 3MHz.

    Thanks,

    Stuart

  • 0 in reply to Stuart Baker
    TI__Expert 6520 points

    Hi Stuart,

    I'm researching this now. It will take a bit of time to reach out to the design team and get additional details. In the meantime can a scope capture be provided to give a little more resolution and detail to the question. It would also be good to understand what the CSz signal is doing if it's being used (or is that D9 MRDY in the capture above?). 

    Thanks,

    Jake

  • 0 in reply to Jake Pulliam
    TI__Genius 10620 points

    Jake,

    I am trying to get a higher resolution capture. We did look at this in the analog domain, and the signals have a nice rise/fall profile with almost zero over/undershoot, so it looks to me like the drive strength on the MOSI line is appropriately tuned.

    The MRDY signal is the CSz signal in the logic capture. It is low during when the issue occurs.

    Thanks,

    Stuart

  • 0 in reply to Stuart Baker
    TI__Expert 6520 points

    Hi Stuart,

    I have feedback from the validation manager that parameters not listed in the data sheet were not characterized. I'm still working with design to see if there is simulation data available.

    Thanks,

    Jake

  • 0 in reply to Jake Pulliam
    TI__Genius 10620 points

    Jake,

    Thank you for your help. I've received an additional high resolution digital image as you requested. I'm also expecting to get an analog domain image. You can see the hold time of the host controller is about 80ns.

    Thanks,

    Stuart

  • 0 in reply to Stuart Baker
    TI__Expert 6520 points

    Hi Stuart,

    I spoke with our designer who worked on that peripheral. Based on his knowledge of the IP and some data he had he states that 100-120ns hold time would be worst case. This covers three system clocks (62.5ns) for capturing the data and potential propagation delays through the IOC. So with the statement above that they achieve >100us is they would definitely be ok.

    BR,

    Jake

  • 0 in reply to Jake Pulliam
    TI__Genius 10620 points

    Jake,

    I realize I made a typo in my earlier email. I said >100us, when I really meant >100ns. Nonetheless, I think you have likely answered our question. I will confirm with the customer.

    Thanks,

    Stuart