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

SDO of Daisy Chain not as expected.

Chip Wachob
Prodigy 110 points
Part Number: DRV8912-Q1

Hello,

The hardware design I'm working with has six DRV89xx parts in a daisy chain.  The chain looks like this:

8912:8912:8908:8912:8912:8908

Below is a log of the SPI data I'm seeing.  I'm concerned that the output is not as one would expect, and in some cases appears to be invalid bit combinations: 

Or, maybe I'm just not understanding the messaging and registers properly.  In which case, I'm happy to be corrected.

All values are hex.

SDO: 86 80 40 40 40 40 40 40
SDI: E0 60 60 60 60 60 43

40
SDO: 00 00 00 00 00 00
SDI: 00 00 00 00 00 00

The intention of this message was to read the status register of each device.  There is no global fault clearing in this message.  This was the first message sent after power up.

Note that device #6 is reporting OTSD & OTW which it is not.  Part is at ambient.  Also, bit 7 is reserved, and shows to be '0' in the data sheet.  (As an aside, I think the Table 54 notes in the right-most column are not completely accurate.  Both bits 5 and 6 indicate over current, but they are over temp indicators)

Devices #5 through #1 are reporting OTSD & OTW, but are clearing MSb as per the data sheet.  Again, parts are not at all warm.

Per the data sheet, the returning headers should match the sent headers.  Obviously there is a mismatch.

Finally, the returned data from the reads is a stream of zeros.  Somewhat expected.  But, this information does not square with the status bytes sent earlier in the bit stream.

Without going into overwhelming detail, this sort of behavior exists with other messages.  For the sake of everyone's patience, I'm omitting those SPI logs but I'm happy to provide them if they would be of use. 

One glaring oddity is when writing to the control register (0x07) returns a part type of 000b for the 8912 devices (correct type) but the 8908 parts are returning 001b (incorrect type).  The 001b code indicating that the part is actually an 8910 part.  I'm doubting that the parts are incorrectly labeled.

I've double-checked and my processor is writing on the rising edge, and reading on the falling edge of the SCK signal which is compatible with Figure 75 on the data sheet.

Thank you in advance for your time,

  • 0
    TI__Genius 13505 points

    Hi Chip,

    Thanks for the detail.  Give me a day to unpack this and see if we can explain what's happening.

    By chance do you have the ability to shorten the chain to rule out any glitches being latched as data?  If I recall our previous conversation, you may have already started with a chain of three devices.  Is this a different board?

    Regards,
    Mike

  • 0 in reply to Michael Erdahl
    Prodigy 110 points

    Mike,

    Thanks.

    Actually returning to answer my own question.  So no need to unpack..  unless I'm misreading the status bits.  In which case, please correct me.

    After I sat here and stared at the output, I realized that it was shifted by a bit.. mostly..  then, I remembered that when the data exits the board (to the next set of six, etc) that I put a flip-flop.. so the clocking of the data was causing that data to be delayed by a bit.

    Yes, this is the same project except I'm now working with my target hardware and not a cobble of EVMs and other boards.

    Sorry for asking, apparently, prematurely.  I had been staring at it all day and couldn't see my way out of the forest for the trees.

    Hopefully, this message will reside in the archives to help someone like me think about other gates in the line.

    Best,

    Chip

  • 0 in reply to Chip Wachob
    TI__Genius 13505 points

    Thanks Chip!

    Glad you were able to sort this and really do appreciate you posting the findings here to help other folks.

    Is the SDI data above in the same order it was received, or did you re-order it to line up with SDO for readability?  I am not seeing the two header bytes being echoed back.  Is this an artifact of the bit delay you mentioned?

    Regards,
    Mike

  • 0 in reply to Michael Erdahl
    Prodigy 110 points

    Mike,

    The data is ordered and aligned as it came out of the SPI analyzer.

    The echoed header bytes in the original post were mangled by the bit shift. 

    After bypassing the filp-flop, the header bits are now carbon copies of the headers which were sent!

    Chip

  • 0 in reply to Chip Wachob
    TI__Genius 13505 points

    Chip,

    OK, that's great.  Did bypassing the flip-flop also clear up the OTSD & OTW bits that were set?

    Regards,
    Mike

  • 0 in reply to Michael Erdahl
    TI__Guru 56650 points

    Chip,

    Let me temporary close this post since MIke takes off this week. if you have some updates needs to put into this thread, you can post it after thanksgiving.