Hello all,

First time poster. This issue is driving me insane as I've scoured the deepest trenches of the internet trying to debug this problem I have on my 4WD robot I designed.

I'm using 2 L298N IC's to drive 4 motors, 2 for the left wheels and 2 for the right wheels. When system drives the robot forward, undefined behavior start happening to the outputs of my MSP432. Such as pins that haven't even been configured begin outputting and driving components outside the scope of this issue. At times, this can freeze the application code and would have to reprogram the uC.

This issue appears to be caused by back emf of changing the direction or stopping the motors suddenly, or so I thought. I included 1N5822 3A schottky diodes on the outputs of the L298N and 100nF caps on Vs and Vss pins (not shown on my schematic, added after), as well as a large 470uF cap on the Vs pin. All as indicated by the datasheet. Also there are 100nF caps on the input and output of the 3.3V Vss level supply.

For my design, I tied inputs IN1 and IN3 together and IN2 and IN4 together. I tied ENA and ENB together and will be driven by PWM output of my MSP432. This is so that a single L298 controls the operation of the two motors of the same side identically, as intended. The motors have a DCR of about 14 ohms and draw a quiescent current of 220mA with a stall of 2A and are rated at 6V. The system is powered by a 6.3V battery, and Vss logic levels is 3.3V.

I've grounded the sense pins and included software delays before toggling the tied inputs (to change motor direction), as mentioned in the datasheet, page 7 of 13. On my PCB I made the output traces 20mils wide as oposed to the signal traces, 10 mils wide.

I can't imagine I didn't cover something. I replaced the chips in case I blew them somehow. In the L298 datasheet it gives a reference PCB design, mine is slightly different but I dont believe this is an issue. The entire robot system without the motors runs great, so I know the issue is this blasted thing. As I searched online and read about 100 threads about the L298 chip, I'm coming to the conclusion that this IC was a waste of time considering how many people have issues with this popular but outdated and apparently ineffective IC. I've already invested so much time so I might as well go online and see what help I can get.

This project is for my senior design class, if this doesnt work I will try to design a h bridge using discrete fets, otherwise I don't graduate and lose my job. I've posted my schematic and pcb.

Please help QQ

 

I also notice when the power to the motors is toggled ( either move forward/reverse and stop) the output voltage OUT2-OUT1 is low. I expect 6V when power off and 3V when on (50% duty cycle right???), but after toggling a few times, it drops to as low as 400mV when off and on to 1.5V.

 

The diodes D1-D8 should be schottky. The 1N400x are very slow.
On your PCB I can see no tracks for the Gnd or power pins on the L298.
One thing I would want to look at is whether any of the motor current flows in a track shared with the logic circuit.

 

The diodes D1-D8 should be schottky. The 1N400x are very slow.
On your PCB I can see no tracks for the Gnd or power pins on the L298.
One thing I would want to look at is whether any of the motor current flows in a track shared with the logic circuit.

The diodes are indeed schottkys, I should have renamed the diodes on the schematic. The pcb is a 4 layer board, so the through hole power pins are connected to the internal power planes when soldered in.

Regarding motor current flowing into the logic signals, that wouldn't be surprising. That could be causing the msp to go crazy when the motors are running. When I get back to lab I'll see what I find regarding this.

Also, the enable and input signal traces coming from the msp are routed pretty closely to the output traces of the l298. Would that be an issue?

 

In general -

1) Motor current ground and UP ground should join at card edge,
so no ground bounce occurs in logic circuits.

2) Hi Z inputs are susceprtable to coupled noise, so either lower their
Z with appropriate drive source conditioning, or add a R to ground
that lowers Z. That burns power, drops noise margin, so a mixed blessing.

3) Use scope on infinite persistence, and look at power rails to see how
much noise you have. Also use single shot sweep, triggering just outside
rails, and see which I/O pin is seeing a lot of coupled noise.

4) Use polymer tantalums for bulk bypass, they are an order of magnitude
better esr performance than regular tants.

Some ref material -

https://www.dialog-semiconductor.com/sites/default/files/an-pm-010_pcb_layout_guidelines_1v31.pdf

http://www.linear.com/docs/42146

http://www.ti.com/lit/an/szza009/szza009.pdf

http://www.st.com/resource/en/application_note/dm00182773.pdf


Regards, Dana.

 

What is the simulation supposed to be? What is the horrendous crud on the unnamed blue signal?

 

In general -

1) Motor current ground and UP ground should join at card edge,
so no ground bounce occurs in logic circuits.

2) Hi Z inputs are susceprtable to coupled noise, so either lower their
Z with appropriate drive source conditioning, or add a R to ground
that lowers Z. That burns power, drops noise margin, so a mixed blessing.

So I got back to the lab and set all unused pins on the MSP as outputs and set to high, and it made a MASSIVE difference. The whole system doesn't trip out when the motors are running, so this DOES mean the noise from the motor current was indeed coupling with the pins on the MSP, because by default reflashing the controller sets all unused pins as high impedance by default. I was going to do this eventually, I just didn't think that was the issue!

Praise the sun! Internet please witness this solution as it may resolve your quarrels.

This doesn't completely fix the issue though. The system is much more stable but a few times, maybe 1/10 times (previously 9/10 times), attempting to stop the motor via a distance reading from an ultrasonic sensor still causes the system to freeze. By freezing meaning the motors won't stop, sink even more current, possibly reducing voltages across the system and causing instability. I'm going to look at some waveforms on the oscope and see what's up.

Is my board design an issue? I have an internal split ground plane, where power and digital ground are met by a single low impedance path. See attachments.

What is the simulation supposed to be? What is the horrendous crud on the unnamed blue signal?

I apologize. In my lack of sleep I uploaded a completely unrelated simulation for a different project.

 

You may benefit from some snubbage.

First be sure to address inductance issues in all external power wiring. Wires to motors should be twisted in pairs, as should the wires to the battery. In general you want to keep the area of current path "loops" as small as possible to minimize inductance and to minimize their ability to radiate.

Snubbers across the motors may help. Because the signal is chopped you have to be careful not to increase power consumption or make things worse. Typically a snubber would consist of a small capacitance in series with a small resistance. The idea is to create a local path for high frequency components. If you use just a capacitor you can make things worse by increasing transient current at the switching edges and often by resonating with the inevitable inductance. The resistor in series with the capacitor helps to fix both of these problems by reducing the peak current and by reducing the Q of any resonant circuit. Without knowing details, I would suggest starting with something in the range of a few tens of nanofarads in series with perhaps 10 to 20 ohms. You need to use an oscilloscope to evaluate performance, which is a bit tricky because you're looking for relative low amplitude ringing on a large amplitude edge. One advantage of the L298 versus newer FET types is that the switching transitions will be slower.

You may get some benefit from adding a decoupling cap or two between the positive ends of the clamping diodes and ground. It looks like this could be quite a challenge, since I don't see any convenient ground access nearby. Ground planes are good things, but there is still only a single point in the whole thing that is "zero volts" so current through the plane can still cause problems. Again the idea is to keep loops local and small.
Generally I think your use of the ground plane is acceptable, though the XBEE module is on a bee line between the power input to the board and U2, which means current for the latter will tend to pass right under the module. The decoupling caps will shift the path downward and keep most of the HF component out from under the module, so I wouldn't expect problems.
As long as it doesn't adversely effect the integrity of the plane I always recommend bringing some vias from the plane to the surface near anything you might want to scope so you can use a tip grounder. On a double sided board with lots of ground foil on the top I like to put void dots in the solder mask for the same purpose. For less critical scoping and general metering I like to have a small wire loop I can attach the ground lead to.

Usually using a good HF capacitor in parallel with a "bulk" cap is a very good thing to do, but occasionally you can produce rather nasty unwanted resonance that spoils your good intentions. It is always worthwhile scoping the power supply in various places. For best results use an active probe if it can handle the voltages involved. Next best is to use a probe tip grounder. If you don't have either, use the shortest probe ground lead possible - the tip capacitance and ground lead inductance form a resonant circuit that can make if very hard to distinguish what is real when fast signals are being examined. Probing the point where the ground lead is connected to the circuit under test is useful and sometimes quite alarming.

Ferrite "beads" can sometimes be helpful to reduce EMI/RFI problems. There are two general classes that might help - very high permeability types and lower perm. "lossy" types. The high perm. type are used for common mode chokes (both wires to a motor wound a turn or two through a toroid). The lossy type act as if you put a frequency-selective resistor in series with a wire. You can find quite useful info at the Fair-Rite website.

 

Ebp, thanks for the reply. This is such a helpful community I greatly appreciate the help.

I twisted the wires to the motors, ill try to twisted the wires from the battery as well.

I read placing small caps across the motors is necessary, so I placed 100nF caps across the terminals of the motors. Perhaps adding some small series resistance to create snubbers would help as well. I will try that.

I have large decoupling caps for the L298's, battery terminals, and regulators. I'll try out more caps across the outputs of the motor drivers.

When I go to the lab I'm going to scope the battery and see if the HF caps are doing any good for me. Maybe I placed too many-- I sort of did when trying to get things to work...

And how would I use a ferrite bead specifically for my system? I'm going to read more about these now.

I'll report back what I find and what progress I make. Technically my problem isn't completely solved so I'm still open yo suggestions.