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.

DRV8243-Q1: DRV8243 can't restart after Vvmuv is removed

Part Number: DRV8243-Q1
Other Parts Discussed in Thread: DRV8908-Q1

Hi team!

The customer used DRV8243S Variant. And when the DRV8243S works normally, they adjust the VM to below 4V and the device can't work. They found that the VMUV is 0b, not 1b. I guess the  DRV8243S Variant's reaction fixed to retry setting. Is that true? But when they adjust the VM to normal work level voltage, it doesn't work.  Can you explain this case? 

  • And it can work after power supply again.

  • Hale,

    And it can work after power supply again

    What do you mean by this statement?  It seems to contradict what you said before that device did not work when VM went back to working level.  

    Please explain more so we can better help.

    Regards,

    Ryan

  • device did not work when VM went back to working level” means that device did not work when the VM from 4V to normal voltage.

    "it can work after power supply again" means that it can work when the VM power off and power on again.

  • Hi Hale,

    Thank you for your question.

    When VM goes down under 4V and go under VM_POR, DRV will go to reset state. Even if VM comes back, CLR_FLT is required to wake up. I guess this info helps. 

    regards

    Shinya Morita

  • Hi Shinya,

    Thanks for your reply. Got it.

    "They found that the VMUV is 0b, not 1b. I guess the  DRV8243S Variant's reaction fixed to retry setting. Is that true?" But why did the customer see the VMUV is 0 bit. The VMUV should be 1 bit to show that the device is in under voltage and we set CLR_FLT 1 bit to make it start. Is that right?

  • Hi hale,

    Thank you for your quesiton.

    >>>They found that the VMUV is 0b, not 1b

    If VM goes down bellow VMPOR_FALL, VMUV should be turned to 0. POR makes reset all registers. So VMUV back to 0.

    regards

    Shinya Morita

  • Thanks Shinya,

    If the VM voltage is between  3.6V~4V, the VMUV should be 1 bit. Is that right?

  • Hi Hale,

    Yes. 

    regards

    Shinya Morita

  • Hi Shinya,

    The customer replied that they need to refresh SPI_IN Register and set CLR_FLT 1 bit when the power supply goes up from 4V to normal voltage, then the device can work normally. Do we have similar phenomenon? 

    Similarly, they found that when they tested device DRV8908 from sleep mode to operating mode, they need set operation control 1/2 register again and give nSLEEP high voltage level, then it can work normally. If not set operation control 1/2 register, the device has no output. Do you have any suggestion?

  • Hi Hale,

    Thank you for your feedback.

    If customer is using SPI_IN function, these register settings also will be reset. Since customer mentioned they need to set CLR_FLT 1, POR could happen and SPI_IN is also reset. I think this could make sense.

    Customer need to re-program all register settings after VM get bellow 3.6V.

    For DRV8908-Q1 question. Please generate new post since this is different device. If VM goes to POR level, customer need to program registers again.

    If you have further questions, let's move to new post.

    regards

    Shinya Morita

  • Hi Shinya,

    I think we might be confused. The customer need to refresh SPI_IN Register and set CLR_FLT 1 bit when the power supply goes up from 4V to normal voltage, then the device can work normally. And if they only set CLR_FLT 1 bit when the power supply goes up from 4V to normal voltage, then the device cannot work normally. The question is why we need to refresh SPI_IN Register. As the datasheet said, we only need to set CLR_FLT 1 bit. What's the reason?

  • Hi Hale,

    Thank you for our feedback.

    Based on customer's description, I think two possibilities.

    1)Customer made VM lower than 3.6V(instead of 4V), therefore POR happens. SPI_IN register back to default value same as other registers. So customer need CLR_FLT and write SPI_IN again.

    2)SPI_IN is unique register bit. In order to change from default value, first customer need to change "SPI_IN_LOCK" as unlock (10b).

    During customer's test sequence, probably this was not done correctly.

    I confirmed that register settings do not turn to reset/default by VM=4V. So SPI_IN registers also should not be reset/default by VM=4V.

    regards

    Shinya Morita

  • As you said 'SPI_IN is unique register bit. In order to change from default value, first customer need to change "SPI_IN_LOCK" as unlock (10b)', the customer changed "SPI_IN_LOCK" as unlock when they tested. And do they need to lock the register after they finishing configuration?

  • Hi Hale,

    Thank you for your questions.

    >>And do they need to lock the register after they finishing configuration

    No need to lock again.

    regards

    Shinya Morita