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.

BOOST-DRV8711 SPI issue

Other Parts Discussed in Thread: BOOST-DRV8711, DRV8711

I am attempting to use a BOOST-DRV8711 module in conjunction with a Hercules MCU evaluation board. I have jumpers running between the headers of the two boards to connect the relevant signals (MISO, MOSI, SCS, SCLK, nSLEEP, STEP, DIR, GND). The DRV8711 module is being powered by 24V, and the power supply return is connected to the GND of both boards.

I have been unable to communicate with the DRV8711 board via SPI. I set nSLEEP high, SCS high, and send a read command (0x8000 for example, to read the CTRL register), but I do not get a response or any activity on the MISO line. I have verified the output of each of the MCU's SPI lines using an oscilloscope and a protocol analyzer. I have verified that the signals are present on the DRV8711 board. The SPI clock speed is 2MHz. I have tried all four clock modes. The MCU is providing a pull-up on the MISO line since I am not providing the DRV8711 board with 3.3V.

I don't know what else to try. Is there something else I am missing?

  • HI Nathan,

    The DRV8711 frames the SPI transaction with SCS. SCS should go low at the end of a 16 bit transaction.

    You can refer to page 25 of the datasheet for more information.

  • It does go low. SCS is high for the duration of the message (16 clock pulses).
  • Thanks Nathan,

    Can you provide a scope capture of the SPI signals?

    Can you also measure the VINT and V5 pin voltages to check that the 8711 is truly functioning? There should be bypass capacitors (C5 and C6) next to each pin that you can measure across easily.

  • V5 (C5) is 4.8V and VINT (C6) is 1.6V.

    Red = MOSI (0xF005)

    Yellow = CSC

    Red = SCS

    Yellow = SCLK

  • I noticed that the MISO line is high when it is not connected to the DRV8711 board, but goes low as soon as I connect it. I applied 3.3V to the DRV8711 board, and now the MISO line remains at 880mV regardless of SPI activity. Could the output be damaged?
  • Nathan,

    Why do you have 5 to the end of the read command? This command will read from register 7 (Status register). If there are no faults this register should read all 0's. Can you try reading from register 0x0 instead (this should have some 1's and 0's).

    SDATO out is an open drain output. It should be pulled high if no transaction is occuring.

    Can you measure SDATO (R3) on the DRV8711 board (no MCU attached) with 3.3V applied and verify it is pulled up to 3.3V.

  • It also looks like you are clocking in data on the falling edge of SCLK. DRV8711 reads data on the rising edge of SCLK.

    SCS should also go high before the first rising edge of SCLK by at least 5ns. Timing table on page 7/8 of datasheet.

  • I read several registers, I just happened to take a screen shot of the STATUS register read command.
    I add 0x5 on the end of the command so that it shows a recognizable, alternating pattern when I look at the signal on the scope.
    I added a 50ns buffer to the SCS toggle (comes on 50ns earlier and turns off 50ns later) and switched the clock phase, but I'm still not getting data back.
    Without the MCU connected, the voltage on one side of R3 is 3.3V, but the other side is 800mV.
  • Thanks for the good info. I am stumped. It looks like the SDATO pin may have been damaged.

    Do you have an MSP430G2 LaunchPad or another BOOST-DRV8711 board on hand?

    You can try the demo application with the MSP LaunchPad to see if the board is working or simply try another BOOST-DRV8711 board with your setup to see if something was damaged on the original.

    Can you also try supplying 3.3V to the BoosterPack 3.3V while trying a SPI transaction instead of using the internal MCU pull up to see if this makes any difference?

  • I ordered a new DRV8711 module and it works just fine. It appears the SDATO pin was damaged.
    Thank you for helping me through the possibilities.
  • Good to hear Nathan. Just let us know if you have any other questions.

  • I continue to have issues with damaging boards.
    I am using two different power supplies to give the DRV8711 board +24V and +3.3V. If I turn on or turn off one of the supplies first, could I be causing damage to the chip?
    The two modes of damage that I am seeing are V5 dropping to 1.7V drawing more current from the +24V power supply, or SDO only getting pulled up to 900mV while idle.
    I have three damaged boards and one brand new one that I am very protective of. I don't want to break my last board. What could be happening?
  • Nathan,

    This is quite strange. I haven't seen this happen anywhere else. Let me investigate on if power sequencing would cause any problems. The majority of our devices are designed to protect against this type of issue. Some questions below:

    Are you connecting the 3.3V to the BoosterPack header J1?

    What type of power supplies are you using for the 3.3V and 24V?

    Are you driving any of the inputs before 3.3V is applied?

    Is there a specific time when the device seems to fail (during motor stall, high speed)?

    Can you place an o-scope on the 3.3V and 24V lines to see if there are any voltage transients occuring that might be damaging the device.

     

  • Are you connecting the 3.3V to the BoosterPack header J1? Yes

    What type of power supplies are you using for the 3.3V and 24V? Two separate bench-top power supplies are being used: +24V to VM and +3.3V to J1 pin 1.

    Are you driving any of the inputs before 3.3V is applied? With power off to the driver board, there could be situations where nSLEEP is high (as a GIO from the microcontroller) or SDO is high (the MOSI line of the micro is setup to pull the line high).

    Is there a specific time when the device seems to fail (during motor stall, high speed)? I have not noticed any specific events.

    Can you place an o-scope on the 3.3V and 24V lines to see if there are any voltage transients occuring that might be damaging the device. I have not seen any.

     

     

    I ordered some samples of the DRV8711 and replaced the chip on two of the non-working boards. The board with the SDO pin error still doesn't work, but a board that has a low V5 problem now works (and has a proper V5 voltage).

  • Nathan,

    I checked with design and there should be no issues with power up sequencing or inputs present before power up for this device, as long as they are inside the Abs Max. ratings.

    It may be good to examine the voltage supplies during motor startup, ramp down, brake, and brake conditions to see if there are any transients on the device pins.

    Please keep me updated as debug continues. I have not seen any issues similar to this.  

  • The board I repaired is still working. I am being more careful about having the driver board powered before the microcontroller turns on. I will keep you updated if I have any other problems.
    I appreciate you working with me on this.
  • I had the 3.3V power on, but not the 24V power (I intended to have it on, but I had forgotten that I had taken my current meter out of the circuit and forgot to hook the cables back up) and connected my DIR/STP/RST/CLK/SLP connector between the driver board and my MCU development board. There was a spike that registered on the 3.3V bench power supply and the 3V3 and 1V2 power supplies on the dev board died. I can no longer connect to the dev board.
  • V5 and VINT on the driver board have also died. V5 = 0.013V. VINT = 0.153V.
  • Nathan,

    Are you saying that the spike occurred when you connected the adapter? Was there only these 5 lines on the connector?

    How is the MCU development board powered? From the same 3.3V supply or a different supply? Is there some sort of ground loop forming?

  • The dev board (TMS570LS12x HDK) is powered by a 12VDC output wall wort that came with the kit. The RST pin was not populated on my connector, but the others were. The spike occurred when I plugged in the connector. The return of the 3.3V bench top power supply and the return of the 24V bench top power supply were connected together and connected to one of the GND pins on the dev board. The effect was that the motor driver board did not have a reference.