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: SPI bus not staying in Hi-Z when unpowered, locks up the bus.

Part Number: DRV8873

Tool/software:

Hello.

We are using a DRV8873 H-Bridge IC. We are seeing a issue when the part is off (no VM applied), it is causing issue with the SPI bus that is preventing the MCU from reading other device on the bus and causing boot issues.

In this pic DRV_PWR is switched and is not always on.

higher level diagram

When DRV_PWR is applied (VM) the bus can recover and we can talk to the low side switch.

Where in the datasheet can i get clarification on this

We have not seen this issue on ~ 1,000 unit (3x boards per unit 4x IC per board) This all seems to happen on the same lot C1V9, this is really a factory question but all the support attempts take me here.

  • Hi Keaton,

    Thanks for reaching out to us via this forum.

    We are using a DRV8873 H-Bridge IC. We are seeing a issue when the part is off (no VM applied), it is causing issue with the SPI bus that is preventing the MCU from reading other device on the bus and causing boot issues.

    Could we please narrow down to a specific SPI pin. Does the SCK look normal? Which of the signals are getting loaded SDO or SDI? Oscilloscope waveforms would be helpful to debug. The block diagram you shared does not show CS (chip select) connections. I'd assume nSCS for the DRV8873 and the CS for the LS switch have separate GPIO pins to control them, correct? 

    An unpowered device may not necessarily guarantee SPI pins would be Hi-Z unless explicitly specified. I can check with our design experts about this device behavior with the SPI pins while the device is unpowered. Meanwhile if you could help us narrow down the affected pin/signal it would be helpful for analysis. 

    We have not seen this issue on ~ 1,000 unit (3x boards per unit 4x IC per board) This all seems to happen on the same lot C1V9, this is really a factory question but all the support attempts take me here.

    If I understood correctly, boards built with lots other than lot C1V9 does not exhibit this problem. Would it be possible to do an A-B-A swap of the ICs to verify and confirm the issue follows the device. Populate one of the boards that has issues with a set of devices with a different lot code as well as populate the devices that had issues to a known good board to verify the issue follow the devices. Also please confirm the failure rate with lot code C1V9 devices was 100%. How many boards exhibit this issue? Thank you.

    Regards, Murugavel