• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 1889 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DRV8301: Noise problems on control electronics

stephen mounioloux
Prodigy 40 points
Part Number: DRV8301
Other Parts Discussed in Thread: TPS54160
Hi

I am working with a speed controller for a 3-phase brushless DC motor.

That motor is taking a 6-12S li-ion battery as input. I have additional electronics that is connected to the same power source through a 5V voltage regulator. I have tried several different types of regulators but I am unhappy with the noise that it's picking up from the switching circuit of the PWM controller on the speed controller.

I am trying to either find a better suited voltage regulator, or to add filtering on the output of the voltage regulator.

As it stands I am measuring up to +/- 5V of noise on the battery when the motor is running. On the output of the regulator I am seeing up to +/- 1.5V of noise which of course is a problem for the electronics on circuit powered by the regulator.

I have not looked at the FFT on the output of the regulator yet, but I think I will do that next.

The motor controller is based on the TI DRV8301 (schematics below) That board also has an MCU for PWM generation, and currently this controlled by a development board, but eventually everything will be integrated on the same PCB, which hopefully helps.

Anyway, the motor controller board supplies 3.3V to the Nucleo board as well as 5V to a sensor (encoder).

Communication between the Nucleo board and the motor controller is proper (SPI), however communication between the Nucleo board and sensor (SPI as well) goes south when the motor is being controlled.

Right now, my best root cause for this issue is a noisy 5V.

As you can see from the schematics, that 5V is generated by the buck regulator on the DRV8301. I knew the voltage out of the buck reg wasn't great which is why I add that low noise 5V regulator, but obviously that's not enough.

The Nucleo board is connected to the motor controller through 3.3V and GND, and the encoder has 5V and GND wired to the motor controller. I have tried a GND to the Nucleo which doesn't help. Those connections are done with dupont wire... for now.

Note: eventually, both MCU will be integrated on the same PCB, but I'm not there yet.

Note: Prior to integrating the F3 MCU and the DRV8301 I had everything working with nothing but dev boards (a Nucleo F3, and TI BoostXL DRV8301). Part of the reasons why I dropped the BoostXL is to also support (and test) the motor which is rated for 48V/8A - which the BoostXL did not support.

We're making a revised PCB with improved ground paths (star connection, with the control ground trace going straight to the DC (-) terminal).

Does anyone have suggestion to reduce the noise generated by the mosfets?

  • 0
    TI__Mastermind 18900 points

    Hello Stephen,

    Thanks for posting on the motor driver forum! Let me give you a more in depth answer tomorrow.

    For now, If the output is picking up the PWM from the motor, you either filter it out or decrease coupling.

    The Buck converter in the DRV8301 is based on the TPS54160 https://www.ti.com/product/TPS54160 , there's lots of good info in the datasheet about how to design the buck filter (with some output filtering suggestions). 

    If you're revising the layout, I'd highly recommend you check out the Best Practices for Board Layout of Motor Drivers app note: https://www.ti.com/lit/an/slva959a/slva959a.pdf . Following the recommendations should help a lot. But you're on the right track, it's all about grounding and making sure the switching current is diverted away from the switch ground of the buck through the use good grounding (as opposed to making the layout worse through ground cut-outs or other not recommended techniques. 

    Best,

    -Cole

  • 0 in reply to Cole Macias
    Prodigy 40 points

    Hi Cole,

    Thank you so much for the reply, this is extremely helpful. I was not aware of that best practice documents, and a quick look seems to be exactly the type of support document I was looking for. I will carefully read it and correct mistakes accordingly.

    Thank you again for the encouraging response, this is refreshing.

    Thanks!

  • 0 in reply to stephen mounioloux
    TI__Mastermind 18900 points

    You're welcome Stephen,

    Last bit of recommendations I can give is to simulate your circuit using TI's Webench Power designer tool, just type in the TPS54160 part number at the top of the page https://webench.ti.com/power-designer/switching-regulator 

    You can simulate transient waveforms stability, see different component selections, and check out a recommended layout. While the layout won't be exactly applicable you might able to find some better components based on your application and figure out which traces should be thicker and which ones can be left thinner, etc.

    Another tip I also want to emphasize is that pins connected to COMP pin are feedback components. Like op amp theory, if the traces are unnecessarily long or use too many vias, you will introduce too much parasitic inductance or capacitance which will change the gain and filtering of the buck feedback. This can affect stability as well. The worst case instability example might be where the PWM Frequency will match up with a bump in the Gain vs. Frequency (Bode) plot which will actually amplify (instead of filter or attenuate) the coupling from the PWM frequency.

    Anyways, happy designing. Feel free to post again if you have any questions.

    Best,

    -Cole

      

  • 0 in reply to Cole Macias
    Prodigy 40 points

    Hi Cole,

    I will post the question as resolved as I am pretty confident this will help. But I wanted to ask one more question and show you a couple of snapshots of what the output of the 5.0 and 3.3V look like.

    I can measure the output of the Buck built into the DRV8301 but it's not as easy because I had not anticipated that it would be useful. Note that at this time I am not positive that the issue is caused by the 5.0V or 3.3V or both. I suspect the 5.0V at the very least based on the behavior of the encoder, where communication is not only altered but the encoder also enters reset state, probably because of an error on its power supply. The 3.3V line is used to power the two MCU's and I have yet to experience reset of either MCU's but they might just be a little more tolerant than the encoder, that being said the communication is also altered, although not as much as than the MCU/Encoder communication. I suspect both regulators are affected, and if the output of the buck on the DRV8301 isn't clean, these 2 regulators are not off to a good start.

    Questions:

    - Is the strategy of setting the buck output to ~ 5.5V, and then regulating down to 5.0V a good strategy? The optical encoder requires both 3.3 and 5.0, and the stability of the 5.0 was critical since it powers the LED. Or would you deem this strategy unnecessary and drop the 5.0V regulator and adjust the buck to output 5.0V instead?

    - Outside of the different packages between the DRV8301 and the TPS54160, would the suggestions made by Webench directly applicable to DRV8301? Or are there any things to watch for?

    - On the spanshots below, is the excessive ringing a typical sign of improper filtering on the buck converter?

    Snapshots:

    - CH1: output of the 5.0V regulator

    - CH2: output of the 3.3V regulator

    - M1: CH1 - CH2

    The period between the main ripples is roughly 14 us or 71.5KHz which is my PWM frequency (I have tried lowering down to ~ 18KHz, which helped with noise but it did not fix resets nor bad communications between MCU's and encoder).

    The first snapshot (zoomed in) shows there is a bit of higher frequency (than the PWM frequency) as well.

    There is a quite a bit of ringing, which tells filtering may not be tuned in properly.

    Thank you again

  • 0 in reply to stephen mounioloux
    TI__Mastermind 18900 points

    Hey Stephen,

    Let me take a look at the waveforms and get back to you tomorrow.

    Thanks,

    -Cole

  • 0 in reply to stephen mounioloux
    TI__Mastermind 18900 points

    Hey Stephen,

    Is the strategy of setting the buck output to ~ 5.5V, and then regulating down to 5.0V a good strategy? 

    Its actually pretty common to do this, buck down from large voltages and then tightly regulate the bucked down voltage for anything related to signal chain and integrity.

    A buck will be used for the large jumps in voltage because its more efficient (from a power losses standpoint) to do this. Then a linear regulator will hold the voltage much more finely than a buck will (because the linear regulator shouldn't be switching). Depending on the regulator's input specification, it might be better to set the buck closer to 5V so the regulator doesn't need to have a "waste more" with the higher voltage drop.

    If the theory doesn't make intuitive sense at first glance, think about power losses of something switching vs. current running through a resistor which represents the buck and linear regulator, respectively.

    Any other suggestions made by Webench directly applicable to DRV8301? Or are there any things to watch for?

    I think the biggest will be how they do the layout and if you want to swap out any components that better suit your application. In general, I encourage you to take a look at what the tool has to offer. You might find something interesting that you want to post a question about to the TPS54160 forum.

    On the snapshots below, is the excessive ringing a typical sign of improper filtering on the buck converter?

    Agreed with your prognosis for the bigger spikes, definitely coming from the motor. Interesting note is the ~600kHz for small 3 in succession pulses, which lines up with Buck frequency. To me, this looks more like issues that can be solved by fixing the grounding.

    As for filtering, I agree filtering could help this but this almost looks like the GND reference is bouncing in this case. So, is the GND bounces where the output filtering cap is located, you'll still see this noise. 

    Best,

    -Cole

  • 0 in reply to Cole Macias
    Prodigy 40 points

    Hi Cole and thank you again for the detailed response.

    I am marking this as resolved as I am pretty sure we will be able to address this issue based on your feedback. If we're still avoid troubles after reworking the ground, we'll let you know!

    thanks again

    Best