• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 46 subscribers
  • Views 203 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.

AMC7834: SPI Timing Spec Questions

Allan Fan
Expert 6010 points
Part Number: AMC7834

Hi expert,

Customer used AMC7834 and have some questions about SPI timing spec e.g. ODZ and OZD although so far no any communication issues. 

What customer measured tODZ is -452ns(spec: 0-10ns) and tOZD is 20.4ns(spec:0-15ns) which are all over the DS timing spec. 

Please help clarify our measurement method or any misunderstanding.

tODZ: 

Q1: referred to fig.2 in DS, is it correct that customer measured tODC from 50% rising edge of /CS to the last bit of SDO?  If so, tODZ is -452ns which is negative and over the 10ns spec.

tOZD:

Q2: referred to fig.2 in DS, is it correct that customer measured tOZD from 50% level of SCLK before the first SDO bit? If so, tOZD is 20.4ns which is over 15ns spec. 

Regards,

Allan

  • +1
    TI__Expert 5440 points

    Hi Allan,

    The Chip Select, Clock, and SDO lines are all driven from your controller, not from the AMC7834 device. 

    T(ODZ): This timing doesn't matter too much in the grand scheme of SPI. All the device needs is to measure the SDO line on the clock pulse. If there are no more clock pulses, the SDO line is ignored. SDO going to High-Z before CS is actually a bit safer, since there's no chance the CS line can go up prematurely and stop communications.

    T(OZD): As long as the SDO has shifted before the next clock cycle, you're in a good place. This is more important for very fast SPI communications. For example,, if you were using the max 15Mhz, each clock cycle would be around 66 ns. The 15 ns T(OZD) timing becomes significantly more important to reach. 

    Again, the timing inconsistencies are from your SPI controller, but due to the flexibility of the the SPI communication system, you wont see any issues.

    Let me know if this helps!

    Thanks,
    Erin