• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 468 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.

DRV8873-Q1: SPI issue after Linux kernel update

Tyler Holmvik
Intellectual 891 points
Part Number: DRV8873-Q1
Other Parts Discussed in Thread: DRV8873

Hello, 

Customer is using 4 daisy-chained DRV8873SPWPRQ1. They have been using this part for a few years now without issue. They are working to update their Linux kernel, but running into issues.

Before the update, they had no issues. After the update, they are seeing strange SPI data. Specifically the SPI data looks correct on the logic analyzer going towards the driver chips (mosi), but the response seen on the bus (miso) is not what is expected. Lots of duplicate values instead of the expected response structure.

Any ideas on what the customer can check here?

Tyler

Here was the original message from the customer:

I have an issue with the DRV8873 SPI daisy chain communications with a newer Linux kernel and would like some help figuring what electrical conditions might affect the SPI output of these chips on our board. In short with a newer NXP kernel the SPI data looks correct on the logic analyzer going towards the driver chips (mosi), but the response seen on the bus (miso) is not what is expected. Lots of duplicate values instead of the expected response structure. So I'm wondering if there is another condition I can check for in the hardware that may cause this. We have 4 drivers in the daisy chain with a single shared CS pin.  

  • 0
    TI__Mastermind 44475 points

    Hi,

    Thank you for your questions. I understood it was operating well but not anymore by their system update. Let me try to guess the potentially related items.

    - DVDD and nSLEEP: Better to double check these voltage level is good(same as before) and no voltage drop while SPI communication.

    -Better to check SPI timing diagram (same as before? frequency faster, less set up/hold margin etc..)

      

    -Better to check SPI command contents.

     Daisy chain requires unique SPI command protocol such as HDR1/HDR2 etc. On datasheet page 31-32.

    regards

    Shinya Morita

  • 0 in reply to Shinya Morita
    TI__Intellectual 891 points

    Hi Shinya, 

    Thanks for the reply. The theory about SLEEP mode is quite plausible. How would the device act during SLEEP? Is SPI disabled during sleep mode?

  • 0 in reply to Tyler Holmvik
    TI__Mastermind 44475 points

    Hi Tyler,

    SPI is inactive. Please refer datasheet 7.4.1.1.

    Thanks,

    regards

    Shinya Morita

  • 0 in reply to Shinya Morita
    TI__Intellectual 891 points

    Thanks for the help so far. Customer has found that the FAULT pin is flagging after sending info from processor. What conditions could cause FAULT flag after sending SPI message?

    Latest information from the customer: 

    I just ran a test on the new kernel using a special bringup image w/out any FES services. The FAULT lines all read 1 to start, then I manually sent this:

     # spidev_test -D /dev/spidev2.0 -v --cpha  -s 500000 -b 8 --input test1-10.bin spi mode: 0x1 bits per word: 8 max speed: 500000 Hz (500 kHz) TX | 84 80 44 44 88 88 00 00 00 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  |..DD......| RX | C0 C0 C0 C0 C0 C0 C0 C0 C0 C0 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  |..........|

     

    Then all the FAULT lines read 0.

     

    Same on older kernel:

     

    here FAULT lines read 1 before and after.

     # spidev_test -D /dev/spidev2.0 -v --cpha  -s 500000 -b 8 --input test1-10.bin spi mode: 0x1 bits per word: 8 max speed: 500000 Hz (500 KHz) TX | 84 80 44 44 88 88 00 00 00 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ _ __ __ __ __ __  |..DD......| RX | C0 C0 C0 C0 84 80 51 51 40 40 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  |......QQ@@|_

  • 0 in reply to Tyler Holmvik
    TI__Mastermind 44475 points

    Hi Tyler,

    Thank you for your update. Good progress that customer found nFAULT=Low. 

    If customer read back status register, it will tell the fault condtion.

    This table also helps to know nFAULT= Low condition.

    And still better to make sure that nSLEEP pin keeps high and no voltage drop.

    By the way, difficult to understand what command is sending from their note. I think customer can narrow down which SPI command create nFault=Low.

    regards

    Shinya Morita

  • 0 in reply to Shinya Morita
    TI__Intellectual 891 points

    Hi Shinya, 

    The customer is unable to get anything other than C0 bytes in response to SPI transfers with the new kernel. With the previous kernel, they do get a response of D8 due to having no actuator motors connected to the board.

    Also, the customer has confirmed that the nSLEEP pin stays high.

    Are there any other ways to know the fault condition without SPI comms?

    Tyler

  • 0 in reply to Tyler Holmvik
    TI__Mastermind 44475 points

    Hi Tyler,

    Thank you for sharing the update. So the issue happens when they connected actuator motor. Then they have the fault condition on DRV. 

    Probably better way is to debug for motor fault condition first with standard SPI communication(not daisy chain).

    Reading out SPI command is easy way to know the fault reason. Otherwise need to check the each possibility(OCP, VMUV) manually. VM, VCP stability can be checked quickly without moving to standard SPI communication.

    I can review their schematic to check.

    regards

    Shinya Morita

  • 0 in reply to Shinya Morita
    TI__Guru 55605 points

    Tyler,

    Is there any further update here?

    Regards,

    Ryan

  • 0
    TI__Intellectual 891 points

    The issue turned out to be a problem with the new NXP kernel.

    The SPI driver wasn't holding down the CS for the full transaction, only 8 bits at a time, so the TI driver chip doesn't know it's in a daisy chain and just returns its status (C0).

    The customer has now fully resolved the issue. Thanks!

  • 0 in reply to Tyler Holmvik
    TI__Mastermind 44475 points

    Hi Tyler,

    Thank you for the update. Good to know this issue is resolved.

    regards

    Shinya Morita