L298, avr: one motor resets my uC:(

[zilch]

Hi all,
I have a problem with l298 driven by attiny2313. I've designed a circuit and ordered a pcb. It seems that it works almost fine, except for one dc motor (connection marked on board image in the attachment)(: When I try to drive this motor, uC resets. I can drive it a *bit* - until the current it takes exceeds 0.1A.
All the other components work fine. I can communicate with the board via rs232, move servos, and play with the other motor. There's no problem at all with the other motor: I can make fast speed/direction switches or stop it by hand and reverse (total current 1A) and nothing bad happens.
The motor is ok too.

I'd appreciate any suggestions.

[Soeren]

Hi,

I have a problem with l298 driven by attiny2313. I've designed a circuit and ordered a pcb. It seems that it works almost fine, except for one dc motor (connection marked on board image in the attachment)(: When I try to drive this motor, uC resets. I can drive it a *bit* - until the current it takes exceeds 0.1A.

Too bad you got the PCB made without asking about it, as there are numerous issues with this layout.
Well done is done, so let's try and compensate by patching the board.

Please post the schematic and a PCB with component values and similar annotations, as it's hard work trying to decipher the board as it shows.
The Eagle files (.sch and .brd) would help as well.

For starters, change the cap immediately right of the regulator with an electrolyte of around 22µF and add a 100nF cap over the controllers supply lines - right at the pins, on the solder side.

[zilch]

Thanks for the reply!
Anyways, I have only that png.image from the previous version. In the new version I have replaced flyback diodes with 1N5822, so the design had to change a bit.

For starters, change the cap immediately right of the regulator with an electrolyte of around 22µF and add a 100nF cap over the controllers supply lines - right at the pins, on the solder side.

I redesigned the board a bit, changing the said diodes, and replacing the first cap you wrote, but I don't which other cap you mean. I see that all supply lines are fitted with 100nF caps.

Too bad you got the PCB made without asking about it, as there are numerous issues with this layout.
Well done is done, so let's try and compensate by patching the board.

I'd rather redesign the board. I can afford one more pcb prototype:) Would you advise to route manually?

[waltr]

I'd rather redesign the board. I can afford one more pcb prototype:)

But ONLY AFTER you get this first board to work properly else you will have a third then a forth etc until one finally works.

Would you advise to route manually?

If you mean not use the auto-router then yes, manually route the board.

[zilch]

But ONLY AFTER you get this first board to work properly else you will have a third then a forth etc until one finally works.

Sure, that's why I'm looking for the reason why the problem occurs. I forgot to mention - I can drive weaker 12v noname motors, but for not example pololu hp 30:1 motor. 

[corrado33]

Could the h-bridge be getting too hot?  

And yes, manually route most of your board, you can let the autorouter do the last few (less important ones).

What are the specs on the motor that shuts it down?

[zilch]

No, the bridge isn't getting hot at all (0.1A can hardly make it even warm). The motor: http://www.pololu.com/catalog/product/993
But this is probably irrelevant, because I can do all I want as rapidly as I wish with this motor on the other channel.

[corrado33]

That's really weird that you can use a different motor and that exact same motor on the other channel and it works perfectly.

I'd say something's weird.  Maybe there is something wrong with your board?  A shorted trace?  Maybe the chip is bad?  I just can't think of any other reason that one channel would work while the other wouldn't.  

EDIT:  Maybe the motor is affecting extremely noisy and shutting the regulator or MCU down.  (I'm just throwing thing out here with no evidence whatsoever.  I tried following the board traces around, but it's... too much of a pain.   )

One thing I do know is... shouldn't you have small capacitors across the leads of the motors as close as possible to them? 

[waltr]

The motor issue is sounding like a Ground path problem on the PCB.
There should be a solid low impedance power and ground path from the battery (PS) to the H-bridge IC.
And the H-bridge IC should have good by-passing to this low impedance ground. An additional bulk cap right at the H-bridge wouldn't hurt either.
You can solder bare wire to improve the ground trace.
A ground plane or pour works much better for a ground.

Also the current path from the PS to the H-bridge should be direct and not pass the processor.
 I see on the first PCB a trace from pin 10 of the IC in the middle of the PCB (processor) to one of the motor diodes. This ground trace is not good!!! Is it when the motor is connected to the bottom connector that there is a RESET? If so that would not be surprising. Cut that trace and run it directly to the H-bridge.

The processor should have its 100nF by-pass cap very close to its Vdd/Vss pins. I don't see this. You can solder a leaded cap directly to the processor pins on the bottom of the PCB.

Exactly what motors do you have? Low cost motors can have big differences from one to the next.
Small value caps on the motor terminals is a good idea as corrado suggests.

[zilch]

Thanks for the reply,

I see on the first PCB a trace from pin 10 of the IC in the middle of the PCB (processor) to one of the motor diodes. This ground trace is not good!!! Is it when the motor is connected to the bottom connector that there is a RESET? If so that would not be surprising. Cut that trace and run it directly to the H-bridge.

Sadly - no, the bottom motor works flawlessly:(

The processor should have its 100nF by-pass cap very close to its Vdd/Vss pins. I don't see this. You can solder a leaded cap directly to the processor pins on the bottom of the PCB.

Exactly what motors do you have? Low cost motors can have big differences from one to the next.
Small value caps on the motor terminals is a good idea as corrado suggests.

The cap was too far from the uC, in the new version it's close to the pins.

I'd say something's weird.  Maybe there is something wrong with your board?  A shorted trace?  Maybe the chip is bad?  I just can't think of any other reason that one channel would work while the other wouldn't. 

EDIT:  Maybe the motor is affecting extremely noisy and shutting the regulator or MCU down.  (I'm just throwing thing out here with no evidence whatsoever.  I tried following the board traces around, but it's... too much of a pain.   )

One thing I do know is... shouldn't you have small capacitors across the leads of the motors as close as possible to them? 

I've tried the caps on motors (and pretty much everywhere:)). Maybe you're right with the broken chip. You're definitely all right that the board is a mess - so I'll try to route a new one manually, possibly learning something in the process, and incorporating your suggestions.

[Soeren]

Hi,

For starters, change the cap immediately right of the regulator with an electrolyte of around 22µF and add a 100nF cap over the controllers supply lines - right at the pins, on the solder side.

I redesigned the board a bit, changing the said diodes, and replacing the first cap you wrote, but I don't which other cap you mean. I see that all supply lines are fitted with 100nF caps.

I repeat, Right at the pins!
Your layout is very weak with hairline traces and decouplings far away from "home" (and other issues).

Too bad you got the PCB made without asking about it, as there are numerous issues with this layout.
Well done is done, so let's try and compensate by patching the board.

I'd rather redesign the board. I can afford one more pcb prototype:) Would you advise to route manually?

Absolutely, I never use the auto-router very extensively, even if I know how to set it up properly and if you don't, forget about using it at all - If you want usable auto-routing, look to programs like Orcad.
But Eagle can do fine stuff if the operator use common sense.

I'm about to catch some Z's soon and after that we're going to Tivoli, Copenhagen with a nephew visiting us from Germany, so I don't know when I'll get around to it, but I will kick your layout through the good old manual router as and when time permits.


One thing you should try, if you haven't already... Swap the motors around - does the problem follow the motor or stay at the same output?
The answer to that may contain a lot of the key.

[zilch]

One thing you should try, if you haven't already... Swap the motors around - does the problem follow the motor or stay at the same output?
The answer to that may contain a lot of the key.

Nope, that doesn't change anything. Maybe the mess in the routed traces is responsible for the problem.. Anyways - thanks, I look forward to reading some more suggestions. In the meantime I'll try to route manually. Have a nice trip, thanks!

[Soeren]

Hi,

One thing you should try, if you haven't already... Swap the motors around - does the problem follow the motor or stay at the same output?
The answer to that may contain a lot of the key.

Nope, that doesn't change anything. Maybe the mess in the routed traces is responsible for the problem..

"Is it an apple or a banana? Yes!"   
How did it not change anything - did the problem follow the motor OR did it stay at the same output?

Anyways - thanks, I look forward to reading some more suggestions. In the meantime I'll try to route manually. Have a nice trip, thanks!

Thanks.
I have been playing around with it, first in Eagle ver 5.7 and when it broke several times (doing the exact same thing) I downloaded ver 5.11, which screwed me over a couple of times as well - Eagle really went sour (and hard to read due to the much lower contrast) starting with ver 5, so I use ver 4.16 for all my own stuff and only ventures into FrankenFive when I have to look at stuff made in that (but the time lost to crashed edits may make it worth redoing it in FabFour.

And in the latest edition, they have spent real estate on making Eagle into a Farnell shopping program - Well, all good things comes to an end   

BTW. You have made the PCB area a little larger than Eagle Freeware allows (4"x3.2") and it isn't started at coordinate 0,0.