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.

DRV10983: Driver did not start the motor properly after few days working

Part Number: DRV10983

Dear TI Support Team,

I am developing with DRV10983.
I succeeded in driving a motor with my new pcb board. ISD, and IPD are all enabled and Motor speed is controlled by I2C Speed command.

However, after several days of testing, there was a phenomenon that the motor did not start envn when I power again the target board.

At this time, even IPD did not work (there was no IPD sound). But in this status, the fault code = 0x00 and MotorSpeed (0x11: 0x12) had some value.

In this case, if I move the motor slightly with my hand, the IPD operation sounds are heard and the motor starts rotating normally.

It was a symptom that did not appear at first, but it continues to occur in many target boards.

The circuit is almost same as the DRV10932 datasheet and has been in normal operation until this occurs and is occurring over time.

Is there any solution to solve this problem?

Best regards,

Peter

  • Hey Peter,

    It sounds like you are powering a board with the DRV10983 and the motor will not start when trying to control the speed via I2C. Sometimes, you are able to get the motor to start driving by "slightly moving the motor with [your] hand". Is this correct?

    Assuming you are not using the DRV10983Z, when the motor will not start, can you read the SpeedCmd and SpdCmdBuffer and see if either are non-zero? Ensuring that the SpeedCmd is nonzero is what will cause the motor to start driving (and the IPD function). If the SpeedCmd is nonzero but to buffer is 0, try to read EEPROM settings when the motor is not starting up and send them to me.

    Also, try disabling ISD or IPD and see if the problem persists. This will narrow down where this problem may be coming from.

    Thanks,

    -Cole

  • Thanks you for your kind reply.

    It sounds like you are powering a board with the DRV10983 and the motor will not start when trying to control the speed via I2C. Sometimes, you are able to get the motor to start driving by "slightly moving the motor with [your] hand". Is this correct?

    --> Yes, It won't start until I touch the motor with my hands

    Assuming you are not using the DRV10983Z, when the motor will not start, can you read the SpeedCmd and SpdCmdBuffer and see if either are non-zero? Ensuring that the SpeedCmd is nonzero is what will cause the motor to start driving (and the IPD function). If the SpeedCmd is nonzero but to buffer is 0, try to read EEPROM settings when the motor is not starting up and send them to me.

    --> I'm not using DRV10983Z.

    ---> Below is the registers of the DRV10983 when it won't start. SpeedCmd and SpdCmdBuffer is not zero.

    ADD DATA
    0x0 0xf4
    0x1 0x80
    0x2 0x0
    0x3 0x40
    0x10 0xf
    0x11 0x0
    0x12 0x36
    0x13 0x4c
    0x14 0xe8
    0x15 0x12
    0x16 0x1d
    0x17 0x4
    0x18 0x0
    0x19 0x0
    0x1a 0xcc
    0x1b 0x7a
    0x1c 0x6d
    0x1d 0x0
    0x1e 0x0
    0x1f 0x0
    0x20 0x5f
    0x21 0x3a
    0x22 0x3a
    0x23 0x8
    0x24 0xc0
    0x25 0xfb
    0x26 0x8f
    0x27 0xbc
    0x28 0x7f
    0x29 0x4a
    0x2a 0x7f
    0x2b 0xe

    Also, try disabling ISD or IPD and see if the problem persists. This will narrow down where this problem may be coming from.

    --> IPS option did not affect the result in my case.

    One more question, does incorrect Kt(lower value than register read value(0x15, 0x16) value affect above situation? 

    Thanks ,

    Peter

  • Hey Peter,

    Thanks for the register data. Let me answer your question first:

    • One more question, does incorrect Kt (lower value than register read value(0x15, 0x16) value affect above situation?
      • The Kt value in the register is calculated by the device. The calculation depends on the speed of the motor (which will generate a larger BEMF to be detected and used to calculate Kt). As a result, the low speed will probably give an incorrect Kt value.
      • However, no, the incorrect Kt value in register does not matter until the device reaches closed loop. So it can be ignored at this point

    So, it seems like there is a value in the speed command (which should trigger start up) and a value speed command buffer (which should shows the device is actively trying to drive the motor). This means something is preventing the process from starting (until you physically move the rotor).

    Can you check the VREG, VCP, and V1P8 voltages on the device (e.g. using a DMM) when the device is stuck in before starting up? The device might be experiencing UVLO or something similar. Also, can you also give me the register values (i.e. register dump) once you've moved the rotor with your hand and the device is successfully starting up?

    Thank you,

    -Cole 

    Edit: I've added your EEPROM settings. Let me know if anything looks incorrect. 

  • Thank you Cole for your reply

    First your added picture EEPROM settings are same as mine.

    Second, register dump and voltage checking are below

    in the scope meter

    C1: VCP

    C2: V3P3

    C3: VREG

    C4: V1P8

    and VCC voltage is 24V.

    You can read the value in the measure window of scope meter

      1) Stuck in before startup

    0x0 0xe9
    0x1 0x80
    0x2 0x0
    0x3 0x40
    0x10 0xf
    0x11 0x0
    0x12 0x1e
    0x13 0x8b
    0x14 0x1e
    0x15 0x0
    0x16 0x18
    0x17 0x4
    0x18 0x0
    0x19 0x0
    0x1a 0xcc
    0x1b 0x74
    0x1c 0x6b
    0x1d 0x0
    0x1e 0x0
    0x1f 0x0
    0x20 0x5f
    0x21 0x3a
    0x22 0x3a
    0x23 0x8
    0x24 0xc0
    0x25 0xfb
    0x26 0x8f
    0x27 0xbc
    0x28 0x7f
    0x29 0x4a
    0x2a 0x7f
    0x2b 0xe

      2) Successfully start up

    0x0 0xf7
    0x1 0x80
    0x2 0x0
    0x3 0x40
    0x10 0xf
    0x11 0x3
    0x12 0x5e
    0x13 0x4
    0x14 0xaf
    0x15 0x0
    0x16 0x8d
    0x17 0x4
    0x18 0x82
    0x19 0xc1
    0x1a 0xcb
    0x1b 0x7b
    0x1c 0x7b
    0x1d 0x0
    0x1e 0x0
    0x1f 0x0
    0x20 0x5f
    0x21 0x3a
    0x22 0x3a
    0x23 0x8
    0x24 0xc0
    0x25 0xfb
    0x26 0x8f
    0x27 0xbc
    0x28 0x7f
    0x29 0x4a
    0x2a 0x7f
    0x2b 0xe

    Can you find anything abnormal?

  • Hey Jihun,

    Based on the waveforms, it seems that VREG is switching rapidly from 3-8V. Is this correct (i.e. this isn't the SW pin)?

    If so, this is not intended behavior which could causing the problem with our device at start up. Please double check the components on the target board match the required external components stated in the datasheet. For reference, VREG should look like 1P8V and 3P3V where the value is seemingly constant but around 5V:

    If they are different, please replace them using the values recommended in table based on which mode is intended during usage (e.g. buck mode or linear mode).

    If they are the same, please review the connections on the layout and schematic and ensure no errors were made and the GND plane is large (i.e. there is a large path for current travel on the SWGND pin).

    Thanks,

    -Cole