DRV8714-Q1: SPI Clock Fault

Frank,

Did they read the register or just monitor nFAULT?  Per the description below, SCLK_FLT is NOT reported on the nFAULT pin.

Also, was the data recognized by the device?  In other words, was the register they were attempting to write to updated?  Data should have been ignored.

Regards,

Ryan

Hi, Ryan，

1. We have read the register, not monitor the nFAULT. In such case, the bit SPI_OK of register IC_STAT1 is always 1. 

2. The data can be written and read correctly from the device.

In the picture, you can see that the time between two 16bit clock is about 1.2us. We want to know the  SCLK_FLT was not set is related to it(1.2us).

And we want to know all the conditions that can leads to SCLK_FLT. At least currently, we sent 32bit clock in one nSCSwe hasn't trigger SCLK_FLT.

Hey Ronglai,

1.2us is much more than the required SCLK minimum period of 100ns, so that time should not be the issue.

Can you post a scope capture of a single SPI transaction (16 bits) more zoomed in? The clock signal looks wavy in your capture above.  

Is this on your PCB or on our EVM?  If EVM, how long are the SPI jumper wires MCU-EVM?

Best,

Jacob

We used a logic analyzer to examine the data. The first 16bits data are normal. The response  of the second 16bits data is random. Can we assume the firt 16bits data were recieved and responded correctly and the second 16bits data were ignored?

Hey Ronglai,

Please give our expert on this device another day to look into this.  

Ronglai Ni said:

Can we assume the firt 16bits data were recieved and responded correctly and the second 16bits data were ignored?

Per the datasheet, SDI pin receiving more or less than 16 bits should cause a SCLK_FLT and the entire transaction to be ignored.  You've confirmed that SCLK_FLT isn't triggering after the transaction, and that the transaction is successfully writing to the device?  Just want to make sure we understand the question correctly.  

Could you test it with less time between the two strings of 16 clock pulses?  

Best,

Jacob

Jacob Thompson said:

Could you test it with less time between the two strings of 16 clock pulses?  

You can see that the response data is different when read the same register(IC_STAT1) using less time between the two strings of 16 clock pulses.

Hey Ronglai,

Hmm interesting. I have posted this to our design team and will let you know what they say, though fair warning it might be a few days.  

Ronglai Ni said:

Can we assume the firt 16bits data were recieved and responded correctly and the second 16bits data were ignored?

If this is what your testing is showing, I am comfortable saying Yes to this question.  Test it first by 1. Read all registers 2. Write to a register.  3. Read all registers and confirm that only the register you wrote to was changed.  Test that on a few registers, and if that checks out then I'd move forward with that conclusion for now unless I can get a more definitive answer.

Best,

Jacob

OK, waitting for your reply. Our customer is very concerned about the result.

Hi Ronglai, 

Thank you for your patience. We will update you as soon as we can.

Best,

Keerthi