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.

DRV8432DKD cycle-by-cycle current limit

Other Parts Discussed in Thread: DRV8412

I am using the DRV8432DKD I have a 24V 6A motor. I have 4.7uH 8A inductor coming from the OUT pins on all four OUTPUTS our PWM Frequency is 25 KHz I am using a.1uF boot strap capacitor. The reason I chose this device is so that I could run in Parallel full bridge mode and have twice the current available but my worst case should be for a constant current of around 9 Amps. this happens with both chips DRV8432DKD (My Board) and the DRV8412 in the DRV8412EVM

 

I am using the DRV8412 in the DRV8412EVM. Rev G.  I have tried the system in 2 different modes 1st in mode 0,0,0 (Dual full bridges with  cycle-by-cycle current limit) and mode 0,1,0 (Parallel full bridge with cycle-by-cycle current limit).  When I change the PWM rapidly it appears that the cycle-by-cycle current limit is being applied, but not in a way that I expect. 

 

If I set the PWM input to a value that causes the system to exceed the cycle-by-cycle current limit the output is clamped to 0 (permanently) until I drive the PWM in the opposite direction.  The fault indicators (fault and otw) are not being lit up which makes me believe it is cycle-by-cycle that is causing the system to stop.

 

 

If I set the PWM input to a value that causes the system to exceed the cycle-by-cycle current limit the output is clamped to 0 (permanently) until I drive the PWM in the opposite direction. 

 

I would expect the clamping to go away just as soon as the current fell below the current limit, but this does not appear to be the case.

 

 

Also the specification does not mention when the Fault should come on the OC should limit the output current via Cycle-by-Cycle when does the Fault actually get set.

 

 

               

  • Gregg,

     

    In CBC current limit mode, the /FAULT pin will NOT cycle low.  The only indication that cycle-by-cycle is working is by monitoring the output and seeing if the output duty cycle is less than the input duty cycle.  Under normal conditions, the output should track the input.  

    Have you used current probes to monitor the actual current you are seeing through the load?  Have you tried increases the OC_ADJ resistor to set a higher current trip point?  

    To see if it is the current protection that is tripping, you could use mode 0,0,1 which would put the device in a dual full bridge mode with latched OC protection.  In this case, the /FAULT will cycle low and the device will latch until the /RESETx pins are cycled or power is cycled.  

    Just to make sure the voltages are normal, you can also scope the GVDD, VDD, DVDD, and PVDD pins to make sure those are all normal under your load conditions.  I have seen these drop out before under heavy load which would trigger the under-voltage protections of the device.  

     

     

  • Yes I have tried to increase the OC-ADJ I am at 24K the max allowed in the table. I did try that mode and confirmed it was Faulting. My design has LEDS to see when this happens like the reference design. All voltages look fine. I do not have access to a current probe I have put a 10AMP meter in series and I have seen up to 7 amps before the unit over currents. I think the problem is that the amount of time needed to detect an over current is to short. It may need to be to protect the chip. All most all of my issues are related to problems during acceleration and deceleration.

     

  • Gregg,

     

    The over-current response time is quite fast at 250ns which is definitely required to protect the IC from damage.  

     

    I just read the message string again.  Are you paralleling the outputs during your testing?  If you are, make sure the outputs are not directly tied together.  A ferrite bead or inductor should be placed between each parallel connected output.  

     

     

  • I have also had similar issues with the part in parallel mode.  Fast direction changes will occasionally cause the part to shut down.  At times I have had the part fail on fast direction changes.  Usually the low side on the second bridge will short to ground.  The part has been quite unpredictable, some will work fine for a month then suddenly fail, others will fail right away.  At this point I am starting to look for a different part.

  • Looks like I Missed the 1000uF @ 63V I have added 440uF @ 50V this helped a lot. Looks like the main problem is during deceleration at lot of voltage is coming back through the motor chip. I would get over currents the faster I tried to stop. Any one have any other ideas for reducing this voltage?

    Tomorrow I will try and add the 1000uF @63V I have ordered them.  

  • Hi Gregg,

    it seems like, the feedback current from the motor causes the over current. If you use the Driver Chip alone, a snubber circuit could help? For a case with KIT, as my understanding, we do not have too much options on the board.

    Expecting ideas from some others and good luck to you.

    Long

  • Gregg,

     

    One of the most effective components for limiting the voltage is a TVS diode on each output to GND.  I have attached a series that you can experiment with.  You want the bi-directional devices.

     

    4380.TVS-SMAJseries.pdf

  • Hi Ryan

     I have never used TVS before Can you make a sugestion as to wich one to start with I have a 24V  8.4A per Output.

     

     

    Gregg

  • Gregg,

     

    I would use something like the SMAJ28CA which gives you margin on 24V operation, but still limits the voltage to less than the recommended 52.5V on the driver.

     

     

  •  

    Hi Ryan

     

    I mistakenly ordered the SMAJ28A which is a unidirectional version they seem to help I put one on each OUT and one on the PVDD as well. Can you tell me why I should use Bidirectional?

     

     

     

     

  • Gregg,

     

    After researching the differences, I think you can get away with a uni-directional device when used in your configuration (output-to-GND).  The uni-directional devices have assymetrical clamping properties...i.e. they will clamp at a normal diode drop when the signal swings below GND, but clamp at the much higher rated voltage for positive voltage swings.  

     

     

     

  • I am still seeing some bad behavior of the CHIP I have a single axes of movement under loads I am seeing some current spikes that are higher than the current limit which stops the drive as you would assume. But occasionally the cycle by cycle does not work because the drive stops but does not show a Fault.

     

    We first noticed this on the DRV8412EVM board we had hoped that by going to the larger chip we would get enough head room to be able to use the chip.

     

    Is there a way to limit the spikes that seem to be coming from acceleration we currently are using 4.7uH/8.25A inductors on each of the outputs. Manufactures part number (DR127-4R7-R)

  • Has there been any resolution to this?  I am also having the same problems with the chip.

     

  • Gregg,

     

    When you say the "drive stops". what do you have to do in order to recover the motion profile?  Cycle /RESET or power-down and back up?

     

    Are you sure that your supply can handle the load and it is not collapsing voltages on the board?  We have seen this numerous times on the DRV8412-C2-Kit when customers try to drive the EVM with the including power supply at more than the rated current.

     

  •  

    Hi  Ryan

     

    Very simple we get errors that are not reported by the fault and the drive just hangs we can reset the chip and it recovers but because it does not tell you with the fault line we have not found a solution to the problem.

     

    As to power it is fine we have a 220w power supply. We have a 100V 30A Diode in line with PVDD so that we do not get high voltages back from the motor when decelerating and we have added a 1000Uf 50V Capacitor as well.

     

    What I think is happening is that we are getting current spikes over the limit and for what ever reason the chip is not telling me it happened. This diode is very important when using a switching power supply because they definitely will shut down if they detect an over voltage.

     

    My next step is I noticed that the 4.7uH inductors that are in the reference design are just too small to protect from some of these spikes so I have ordered some 22uH to try. I may even try 100uH.

     

     

  • Hi,

    we are developing a motor control where it is quite important to accelerate and break quit impulsive. We are working with the DRV8432. In our prototype as well as in the evaluation board of TI we are having the same effects that Gregg described in his first post:

    We configure the board for working in parallel mode, attach 12V control power, 30V motor power, a motor and start PWM at 70% duty cycle at PWM_A. PWM_B is held low. The motor only moves very short, and we can see a short current peak coming up to overcurrent limit. After that, there is still some current but it is a decreasing ripple while the motor does not turn.

    After reading the post and discussing it internally, we had the idea, that the overcurrent limit of the not-switched path did come first and switched of (waiting for the next cyle - which does not com as PWM_B is held constant low). So the lower switch of "B" path which should be closed is kept open and the upper switch of that path is closed while the "A" path continues with its cycles as overcurrent events are resetted by CBC-OC-Control.But those PWM of the "A"-Path have no effect anymore.

    We tested that theory and gave a short "high" Peak on the PWM_B-Signal during the High Level of the PWM_A-Signal - and it worked, the Motor is accelerating right now.

    It is a bit strange as we expected the CBC-overcurrent-control only to be active in the pulsed switch, not in the static switch.

    Perhaps a specialist of TI could confirm our theory and give us a hint, how we can handle the problem. I do not like to play around with PWM_B while I'd like only to accelerate with PWM_A. Is there any workaround, some code example or some schematic tricks and guidelines to handle that problem?

    Thanks a lot,

    Sebastian

  • Sebastian,

     

    I do believe that you hit the proverbial nail on the head with your analysis.  Well done as I wasn't thinking in that direction on previous posts.  You gave me the information that I needed to understand what was going on.  

     

    If the "un-switched" output hits CBC limit before the switched output, than the part is essentially stuck in a CBC limit mode and a 50ns pulse on that output is the only way to bring it back out.  As noted in previous posts, there is no reporting on this condition to report back to the micro.

     

    After discussing internally, the only workaround is what you have discovered which is to place a minimum 50ns pulse on "B" output.  As long as the duty cycle on "A" exceeds that 50ns pulse, then the motor will turn in the proper direction.  

     

    The other workaround is more obvious, and probably less desirable, which is to increase the OC trip level or put the device in a latched mode that will issue a /FAULT.  

     

     

  • Hi Ryan,

     

    thank you for reply. With the workaround, the evaluation board is running. Sadly it does not work in our design: The motor is running well, but the current is not limited at all.I already treid to go back to use only one single bridge and could see some influence caused by the inductor.

    When I do not use the inductors at the evaluation board the motor does not move in any way. Can you give me some hints what could be the reason for the missing current limiting, and what I can check for finding the problem?

    Thanks and have a nice weekend,

    Sebastian

  • I must appologyze: The problems with overcurrent-limitwere caused by a wrong resistor-value at this pin - we switched two neigbourged resistor. Now our own circuit runs quite well.

    Regards,

    Sebastian

  • Sebastian,

     

    Glad to hear it and thanks for the update.