Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

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.

CCS/DRV8301: DRV8301 FAULT STATUS REPORTING ISSUE

Part Number: DRV8301
Other Parts Discussed in Thread: TMS320F28377S

Tool/software: Code Composer Studio

I am using a DRV8301 gate driver and a TMS320F28377s MCU to control a BLDC motor. 

When a fault is detected, the MCU reads the DRV8301 status register 1 to take appropriate action. The problem is that after an over-current condition, the DRV8301 only sets bit 10 which is a generic "fault" flag.

Please see Fig. 1 for SPI comms. scope capture immediately after an over-current fault. 

 

It would be really useful if the appropriate bit indicating what type of fault has occurred was set. Can anyone advise why this is not happening? 

Please also see Fig. 2 for control registers SPI read capture.

Thanks,

Tony

  • Hi Tony,

    How are you testing the overcurrent condition?

    Which overcurrent protection/reporting mode are you using? We have four of them, and they each handle faults differently. Could you try different modes to see if you can read the fault bit for the corresponding FET?

    Reading Status Register 1 clears the FET fault bits if any are set. Is it possible that you accidentally read the register but do not store the data before you intend to?
  • How are you testing the overcurrent condition?

    - By applying an increased mechanical load to the motor, which is in speed control.

    Which overcurrent protection/reporting mode are you using?

    - OCP_MODE is set to 'latched shut down' (see Fig. 2, control register read). I also have OCTW_MODE set to ‘report OC only’ and have observed that this pin is pulled low briefly after an OC event.

    Reading Status Register 1 clears the FET fault bits if any are set. Is it possible that you accidentally read the register but do not store the data before you intend to?

    - Fig. 1 shows the first SPI transaction immediately after an OC event. Here control register 1 is written so that the return 16 bit word is the value of status register 1, which can be seen to have only BIT 10 (the general “fault” bit) set.

    It should be noted that EN_GATE is held high when Figs. 1 and 2 were captured.

    Any suggestions are greatly appreciated.

    Thanks

    Tony
  • Tony,

    I'm wondering if the device somehow is experiencing both an OCP event AND a UVLO condition on PVDD. Do you have long leads from your supply to your board? Also do you have some kind of current-limiting feature on your supply?

    The large current from your stall condition may cause a voltage drop across the supply leads which may cause the device to go into UVLO. The same thing would happen if you have current limiting on your supply - the supply voltage drops and the device goes into UVLO. When UVLO triggers, the SPI registers go to default values, but a fault is reported on the nFAULT pin and in SPI. The nOCTW briefly turns on because the overcurrent condition was also observed, however this will be overridden by the UVLO after the 15 us deglitch time.

    To check this, could you please take a scope shot of PVDD1 (measured close to the pin), nFAULT, nOCTW, and the supply current?
  • James, 

    I have beefed-up the DC supply cables and noticed the FET OC bits getting set today, although this was with a different (lower inductance) machine.

    I will scope the signals you suggest with the original motor and report back. 

    Thanks

    Tony

  • James, 

    The reasons behind the issue I was seeing were as follows:

    1. Momentary DC bus under-voltage.

    2. OCTW bits set to 01. I thought the OCTW bits controlled reporting on the nOCTW pin only. 

    I found I needed a 6A supply to trigger the OC  bits successfully, so thanks for your suggestion. 

    Regards,

    Tony