• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 311 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.

DRV8305: SPI Transfer Timeout

Jacob Wyrick
Expert 8365 points
Part Number: DRV8305

Hi team,

Looking at the datasheet, I'm curious if there's a SPI transfer timeout for the communication. Another description would be is there a time where, if the SPI communication takes longer than x micro/nanoseconds the communication times out.

Does that exist?

Working off the specs given in the datasheet, the SPI timing requirements has the minimum SPI clock period at 100ns (Table 6.6). During SPI communication, the DRV8305 is looking for 16 bits of data (Section 7.5.1.1). If the data to SDI =/= 16 bits, then it’s considered a frame error and the communication is ignored.

Multiplying it out, I’d think that anything longer than 1600ns would not be valid. I guess another way to put it would be that SPI commands would all have to execute within 1600ns to be valid.

Is that accurate?

Thanks,

Jacob

  • +1
    TI__Mastermind 18981 points

    Hi Jacob, 

    Thanks for posting your question to the motor drivers e2e forum - 

    Let me look into this further with the team to see if there's a timeout condition 

    • Understood that in SPI protocol described in the datasheet, a frame error will ignore the command if anything other than 16 bits is received 
      • However, as you mentioned, I don't see a spec for the maximum time period for the SPI clock period or SDI input period 
    • Instead, I think the criteria for SPI frame #bits will actually just be the window of the nSCS (chip select) pin being Low. 
      • e.g. when nSCS is toggled High again, the # of bits received while nSCS=L will be checked. If !=16, then an error occurs and SPI frame ignored. 
      • this mechanism may not be time-sensitive, since I feel like my team members have tried bench scripting w/ operating SPI even as slow as 30microSeconds for one SPI frame without issue 
         

    Thanks and Best Regards, 
    Andrew 

  • 0 in reply to Andrew Liu
    TI__Expert 8365 points

    Hi Andrew,

    Thanks for the thoughts.

    Now that I think about how the timing is spec'd, the minimum SPI clock period would actually mean that 100ns is the shortest duration so that'd actually be 1600ns as the shortest possible SPI message.

    I think your comments make sense. Let me know what the team says regarding the timeout condition!

  • 0 in reply to Jacob Wyrick
    TI__Mastermind 18981 points

    Hi Jacob, 

    You would be correct that the interpretation is inversely related (that max SPI freq corresponds to min clock period)!

    • one other clarification I'd like to add is that the 1600ns is just for the actual clock pulses themselves,
    • and the 1600ns estimate doesn't yet include all the setup/hold time delays described in the 'SPI Timing Requirements' datasheet section 

    I'll keep you updated on the timeout condition discussion w/ my team members

    Best Regards, 
    Andrew 

  • 0 in reply to Andrew Liu
    TI__Expert 8365 points

    Hi Andrew,

    Thanks for the further explanation. Let me know what you hear back from the team!

  • 0 in reply to Jacob Wyrick
    TI__Mastermind 18981 points

    Hi Jacob, 

    Will do - I'll follow up with them for a response, aiming today/tomorrow

    Best Regards, 
    Andrew 

  • 0 in reply to Jacob Wyrick
    TI__Mastermind 18981 points

    Hi Jacob, 

    From discussion w/ the team, I believe that my earlier response should be correct for this device - 

    Should be able to slow down SPI communication as long as you're following the SPI datasheet requirements for timing, frame format, and addr/data values. 

    Best Regards, 
    Andrew