AVR Freaks

AVR Microcontrollers, megaAVR and tinyAVR

Level: Hangaround

Joined: Mon. Mar 5, 2012

Posts: 108 View posts

Location: Turin, Italy

Posted by thexeno: Fri. Aug 2, 2013 - 02:17 PM

Hi! :D

First: EMI = ElectroMagnetic Interference

I've recently wrote a small application to handle a PWM signal for a DC motor (generic, so maybe the PWM frequency could be not the optimal).
My board is an Arduino 2009 (for electrical knowledge) and I wrote the program in C unsing Atmel Studio 6.

It receive by UART a letter (a or b), space, number (0-255) and \n and manage this string to set the direction (a or b) and PWM DC (0-255) generated by the Timer 0. Optionally, I can use 2 buttons by interrupt (PCINT23 and PCINT0) and a potentiometer disabling the last data received by USAR allowing control to a user, in a joystick fashion control.

I've done this connecting my motor with a L293DNE driver, usign 2 channels per signal allowing to drive up to 1A.

Powering it with an external (or USB, is the same result) power, ONLY with PWM frequency >3,9Khz (prescaler less than 8, with 16Mhz -> see Duemilanove board) if I lock the motor, at higher DC (almost 100%) the program "crash". If would be an energy supply problem, the MCU should reset or not executing anymore instructions. BUT in my case, is not rsponding to UART commands neither variations to ADC value. When I meet this bug, motor is stucked at the last DC. But even the other pin (the one that should be a PWM with DC=0%=GND), now, is generating a different PWM, with total result PWM different from the one in output at the first pin.
Surprisingly, my MCU still receive button commands and reverse the rotation while proper button is pressed. But don't change the PWM, don't respond to serial, don't stop the motor if I open the button, it just reverse the rotation. It's like my MCU is in coma, and work weird.

You can read my code, here attached.

NOTE: when this AVR "coma" comes up, is when the motor driver send back more than 10V of overshoots from the motor (with a motor locked, case when mcu will start acting weird, but still dependent on its inductance) to the digital outputs. I saw that on oscilloscope.

Attachment(s):

pwm_alfa.rar

Tags:

Brutte

Level: Raving Lunatic

Joined: Thu. Oct 5, 2006

Posts: 3229 View posts

Location: Poland

Posted by Brutte: Fri. Aug 2, 2013 - 02:38 PM

you meant:

OP wrote:

If would be an energy supply problem,

and

then:

OP wrote:

the MCU should reset or not executing anymore instructions.

No RSTDISBL, no fun!

Level: Resident

Joined: Tue. Jul 19, 2011

Posts: 708 View posts

Posted by Chuck-Rowst: Fri. Aug 2, 2013 - 03:02 PM

thexeno,

This sounds like a simple case of the processor getting clobbered from some direct voltage interaction with motor activity. I would eliminate this possibility forst, befpore persuing any EMI remedies.

The usual test exercise in this situation is to power the motor and the processor/control circuitry from two separate supplies (but with a common, well-placed ground connection between the two supplies.)

The ultimate remedy is typically to provide enough "isolation" between the micro & control circutiry voltage supply and that of the motor.

What is your power supply for this? Battery? AC Line? Automotive?

WHat voltage does the motor run at? What voltage is the AVR running on?

Level: Hangaround

Joined: Mon. Mar 5, 2012

Posts: 108 View posts

Location: Turin, Italy

Posted by thexeno: Fri. Aug 2, 2013 - 03:15 PM

Brutte wrote:

you meant:

OP wrote:
If would be an energy supply problem,

and

if temperature is within range, if absolute maximal voltages on IOs are met
if the chip was not abused yesterday evening
if the BOD is enabled
if clock is within frequency vs voltage range
if power rail capacitors are there
if reset pin is not dangling
(here there are 23 other ifs)
then:

OP wrote:
the MCU should reset or not executing anymore instructions.

I've used the Arduino 2009 board, I mentioned it as its schematic is online. So everything is well dimensioned. http://arduino.cc/en/Main/ArduinoBoardDuemilanove
I've used the Arduino bootloader, since I don't have a programmer, so I have the correct fuses set for that HW.

I've posted the code as you can see what I've initialized in the atmega329P. The rest has its own reset value (See datasheet).

Chuck-Rowst wrote:

What is your power supply for this? Battery? AC Line? Automotive?

WHat voltage does the motor run at? What voltage is the AVR running on?

You're right. As a first place, see the schematic at link above, you can understand how power switching between USB and external power works.

In second place, considering that schematic, I'm using 5V for all the system (Arduino+Motor+Driver), in output from the LDO (see schematic). The 5V regulator became hot, but for short periods it can work without issues.

The Arduino is connected to USB of my PC and receive power from a 9V 1500mA transformer (classic old 50Hz tranformer, no switching) rectified with cap+diodes (and it has also a ferrite!)

jccordill

Level: Hangaround

Joined: Fri. Feb 19, 2010

Posts: 402 View posts

Location: Olathe, KS

Posted by jccordill: Fri. Aug 2, 2013 - 06:36 PM

Do not supply power for your motor from the 5v regulator on the arduino, it pulls to much power for the regulator to handle, so it gets hot and shuts down.
Power the motor from it's own separate power source.
Ask if you need help on how to do that.
JC

Level: Hangaround

Joined: Mon. Mar 5, 2012

Posts: 108 View posts

Location: Turin, Italy

Posted by thexeno: Fri. Aug 2, 2013 - 07:27 PM

jccordill wrote:

Do not supply power for your motor from the 5v regulator on the arduino, it pulls to much power for the regulator to handle, so it gets hot and shuts down.
Power the motor from it's own separate power source.
Ask if you need help on how to do that.
JC

I've sperimented that case: the 5V simply dropdown and system will be reset.
The regulator has an internal protection (thermal and current). If the voltage do not drop down, the protection is still not active.
This mess comes up only with PWM greater than 4KHz, approx. Less of this value, this setup works fine (the regulator too). The only difference is this huge overshoot that came back to micro.

after saying that, I remind you that I am conscious that make connections like me is not the ideal. I need to put in safe the micro from motor's spikes etc. But with this setup, I'm pretty sure that the problem, as I just said, is due to those spikes from motor. And how they interact to the MCU make it act so strange.

I'm pretty sure too that following your advices everything will be solved, and I'll try.

But I'm sure that with AvrFreaks I will figure out what is trigger this buggy mechanism. It should stop, reset, explode, burn, but a digital device (an unbroken device) can't work only a bit. It is like its main() function will be skipped executing only ISR. Of course this cannot happen (see code).

Level: 10k+ Postman

Joined: Thu. Dec 30, 2004

Posts: 24774 View posts

Location: Melbourne,Australia

Posted by Kartman: Sat. Aug 3, 2013 - 12:15 AM

The AVR, like just about every other microprocessor is a sequential logic device. This means it has flip flops - lots of them. The ram is comprised of flip flops. What is a flip flop? Refer to wikipedia- basically a bistable logic device or simply a 1 bit memory. Introduce a voltage spike and you have no idea of what flip flop will get affected. Net result is the ram may be corrupted,the registers may be corrupted,the ports may be corrupted and/ or the program flow.high energy particles can cause the same thing. So in the real world, your microprocessor isn't too reliable. It can temporarily fail in a random manner.
This is what you are observing.

It is not a good idea to power your motor from the same power rail as your processor. Apart from spikes, the main problem is brown outs as the motor can pull peak currents and starve the avr of power temporaily.

You also need to be aware of where the current is flowing. You do not want the motor current flowing across the Arduino pcb no matter how "well dimensioned" it is. The 0V for the motor must come from the power supply source, not via the arduino. The concept here is a "star" point. All 0V volts converge at one point - usually the connector where the power comes in.

The L293 allows you to run a separate power source for your motor vs the logic power.use this facility.

Since the motor has inductance, if you interrupt the flow of current you will get voltage spikes. Interestingly enough, the commutator of the motor interrupts the current on a regular,basis, so you get lots of spikes from a motor. Normally a ceramic capacitor across the motor will fix most issues but for larger motors a varistor will usually do the trick. I had a project where i was switching 10+ amps to dc motors using relays. The opto isolated usb to serial converter would get upset when the motors switched. The AVR wasn't affected ( and subsequent EMC testing showed the design was fairly immune to spikes). Putting varistors across the motors solved the problem.

Level: Hangaround

Joined: Mon. Mar 5, 2012

Posts: 108 View posts

Location: Turin, Italy

Posted by thexeno: Sat. Aug 3, 2013 - 10:50 AM

Kartman wrote:

The AVR, like just about every other microprocessor is a sequential logic device. This means it has flip flops - lots of them. The ram is comprised of flip flops. What is a flip flop? Refer to wikipedia- basically a bistable logic device or simply a 1 bit memory. Introduce a voltage spike and you have no idea of what flip flop will get affected. Net result is the ram may be corrupted,the registers may be corrupted,the ports may be corrupted and/ or the program flow.high energy particles can cause the same thing. So in the real world, your microprocessor isn't too reliable. It can temporarily fail in a random manner.
This is what you are observing.

It is not a good idea to power your motor from the same power rail as your processor. Apart from spikes, the main problem is brown outs as the motor can pull peak currents and starve the avr of power temporaily.

You also need to be aware of where the current is flowing. You do not want the motor current flowing across the Arduino pcb no matter how "well dimensioned" it is. The 0V for the motor must come from the power supply source, not via the arduino. The concept here is a "star" point. All 0V volts converge at one point - usually the connector where the power comes in.

The L293 allows you to run a separate power source for your motor vs the logic power.use this facility.

Since the motor has inductance, if you interrupt the flow of current you will get voltage spikes. Interestingly enough, the commutator of the motor interrupts the current on a regular,basis, so you get lots of spikes from a motor. Normally a ceramic capacitor across the motor will fix most issues but for larger motors a varistor will usually do the trick. I had a project where i was switching 10+ amps to dc motors using relays. The opto isolated usb to serial converter would get upset when the motors switched. The AVR wasn't affected ( and subsequent EMC testing showed the design was fairly immune to spikes). Putting varistors across the motors solved the problem.

This can be reasonable. It can introduce a mess in internal registers and corrupting SRAM too.

About the spikes, the reason are the driver diodes too slow? Since there are basically no spikes at lower PWM feequencies.
I've also capacitors soldered on motor, but they can't be big enough, so ok for that.

Level: 10k+ Postman

Joined: Thu. Dec 30, 2004

Posts: 24774 View posts

Location: Melbourne,Australia

Posted by Kartman: Sat. Aug 3, 2013 - 11:40 AM

How do you know there are no spikes at lower frequencies? Unless you have measurements, you're only guessing. I would suggest you try a separate power supply for the motor and rule out brown-outs.

Level: Hangaround

Joined: Mon. Mar 5, 2012

Posts: 108 View posts

Location: Turin, Italy

#10

Posted by thexeno: Sat. Aug 3, 2013 - 12:15 PM

Kartman wrote:

How do you know there are no spikes at lower frequencies? Unless you have measurements, you're only guessing. I would suggest you try a separate power supply for the motor and rule out brown-outs.

There aren't, or they're less than half volt, and this is right, since I've flyback diodes. I used an oscilloscope (and MCU works fine).

Level: 10k+ Postman

Joined: Thu. Dec 30, 2004

Posts: 24774 View posts

Location: Melbourne,Australia

#11

Posted by Kartman: Sat. Aug 3, 2013 - 12:47 PM

So what happens when you run higher pwm frequencies? What measurements have you made?

31Khz_pinMCU_highDC_motore_bloccato.JPG

Level: Hangaround

Joined: Mon. Mar 5, 2012

Posts: 108 View posts

Location: Turin, Italy

#12

Posted by thexeno: Sat. Aug 3, 2013 - 04:28 PM

Kartman wrote:

So what happens when you run higher pwm frequencies? What measurements have you made?

Since this happens when I stall the motor with my fingers, its inductance send back a lot of spiekes. I saw this by applying a scope on the active pin of the motor (the other is suppose to be GND, no PWM on it). The same, a bit different but still with a lot of spikes, is what I see at PWM pin of micro (input of driver). I didn't made measurement at other pin of the micro, the one that should be always 0.

Attached here, you can see my ugly picture of what is present at MCU pin. settings: 2V/DIV - 10us/DIV

Attachment(s):

Brutte

Level: Raving Lunatic

Joined: Thu. Oct 5, 2006

Posts: 3229 View posts

Location: Poland

#13

Posted by Brutte: Sat. Aug 3, 2013 - 08:08 PM

MCU killer wrote:

Attached here, you can see my ugly picture of what is present at MCU pin. settings: 2V/DIV

This looks like 13V p-p.
Any other ratings violated?

No RSTDISBL, no fun!

Level: 10k+ Postman

Joined: Thu. Dec 30, 2004

Posts: 24774 View posts

Location: Melbourne,Australia

#14

Posted by Kartman: Sat. Aug 3, 2013 - 11:16 PM

How about a picture of your setup?

One needs to be careful as to how you actually measure. The earth lead of the 'scope tends to pick up a lot of signal a give you an inaccurate picture. Nevertheless, I'd say you've got major problems.

Level: Hangaround

Joined: Mon. Mar 5, 2012

Posts: 108 View posts

Location: Turin, Italy

#15

Posted by thexeno: Sun. Aug 4, 2013 - 10:40 AM

Brutte wrote:

MCU killer wrote:
Attached here, you can see my ugly picture of what is present at MCU pin. settings: 2V/DIV

This looks like 13V p-p.
Any other ratings violated?

MCU killer says that are not other ratings violated. As it seems, internal Atmega protection works well. Is still alive (and happy).

Kartman wrote:

How about a picture of your setup?

One needs to be careful as to how you actually measure. The earth lead of the 'scope tends to pick up a lot of signal a give you an inaccurate picture. Nevertheless, I'd say you've got major problems.

I've 5cm of breadboard cable from Arduino to a DC motor board (http://www.adrirobot.it/robot_deagostini/scheda_motori/scheda_motori.htm) and about 5cm from this last one to the motor. At those freqs is not a problem of receiving EMI. The earth has 10Vpp 50Hz without the GND, but without the GND nothing can work or be consistent.

Level: 10k+ Postman

Joined: Thu. Dec 30, 2004

Posts: 24774 View posts

Location: Melbourne,Australia

#16

Posted by Kartman: Sun. Aug 4, 2013 - 10:51 AM

Quote:

At those freqs is not a problem of receiving EMI.

Really? I think you are underestimating the problem.

Quote:

The earth has 10Vpp 50Hz without the GND, but without the GND nothing can work or be consistent.

That tells us very little - you stated the obvious.

The layout of your interconnections is critical.

Level: Hangaround

Joined: Mon. Mar 5, 2012

Posts: 108 View posts

Location: Turin, Italy

#17

Posted by thexeno: Sun. Aug 4, 2013 - 05:12 PM

Kartman wrote:

Quote:
At those freqs is not a problem of receiving EMI.
Really? I think you are underestimating the problem.

Quote:
The earth has 10Vpp 50Hz without the GND, but without the GND nothing can work or be consistent.
That tells us very little - you stated the obvious.

The layout of your interconnections is critical.

You could be right. After all, I'm just a student in electronic engineering, with a very little experience in this kind of problems. Just to set the level of conversation.
...and just to be hilarious, about the criticism of layout, you stated the obvious too. :)

I don't need to do a better layout now. but understand, with that noise signal, how and why MCU works in this way.

Level: 10k+ Postman

Joined: Thu. Dec 30, 2004

Posts: 24774 View posts

Location: Melbourne,Australia

#18

Posted by Kartman: Sun. Aug 4, 2013 - 10:47 PM

Well, something got lost in the translation as I'm not laughing.

Level: Hangaround

Joined: Mon. Mar 5, 2012

Posts: 108 View posts

Location: Turin, Italy

#19

Posted by thexeno: Sun. Aug 4, 2013 - 11:30 PM

Kartman wrote:

Well, something got lost in the translation as I'm not laughing.

I needed to seem not too rude and respectful.
btw, Laughing or not, my "issue" remains.

Level: 10k+ Postman

Joined: Thu. Dec 30, 2004

Posts: 24774 View posts

Location: Melbourne,Australia

#20

Posted by Kartman: Sun. Aug 4, 2013 - 11:44 PM

The basic mechanism is that the interference violates voltage and/or timing requirements. The net result is indeterminant. This is a complex problem.

Read up on the TI hercules range of microcontrollers to see the steps they take to address the issue of random disturbances.

Level: Hangaround

Joined: Mon. Mar 5, 2012

Posts: 108 View posts

Location: Turin, Italy

#21

Posted by thexeno: Mon. Aug 5, 2013 - 08:50 AM

Kartman wrote:

The basic mechanism is that the interference violates voltage and/or timing requirements. The net result is indeterminant. This is a complex problem.

Read up on the TI hercules range of microcontrollers to see the steps they take to address the issue of random disturbances.

Thanks a lot! All this stuff/problems encountered are very instructive!

Level: Resident

Joined: Tue. Jul 19, 2011

Posts: 708 View posts

#22

Posted by Chuck-Rowst: Mon. Aug 5, 2013 - 01:57 PM

thexeno,

I assume the O-scope picture you posted was taken while the problem was active. (I think you said you squeezed the motor shaft with your fingers to get the spikes to cause the problem.)

What pin is this on the micro?

Can please you post an O-scope picture showing exactly the same pin's voltage while the problem is NOT occuring. And perhaps another when you are squeezing the motor shaft lightly, but not hard enough to actually cause the problem?

GND of motor locked (L293D side)

Level: Hangaround

Joined: Mon. Mar 5, 2012

Posts: 108 View posts

Location: Turin, Italy

#23

Posted by thexeno: Wed. Aug 7, 2013 - 02:35 PM

Chuck-Rowst wrote:

thexeno,

I assume the O-scope picture you posted was taken while the problem was active. (I think you said you squeezed the motor shaft with your fingers to get the spikes to cause the problem.)

Yes. But with motor fully locked. Electrically speaking is very similar before the issue. Due to this waveform the MCU works bad. And the waveform is still there when the MCU has started to work badly.

Quote:

What pin is this on the micro?

OC0A and OC0B were the 2 pins. When I use one or the other, the problem is the same. (on atmega328P DIP)

Quote:

Can please you post an O-scope picture showing exactly the same pin's voltage while the problem is NOT occuring. And perhaps another when you are squeezing the motor shaft lightly, but not hard enough to actually cause the problem?

I don't have the setup under my hands, but I can post the rest of pictured that I taken that day.
I don't have the picture of the motor lightly shafted, but the waveform that you can see on motor shaft, is start to shaping in that way when I start to apply a force to the motor.

PS: the first pic of this 3D refers to signal on MCU side, while these refers to L293D side.

Attachment(s):

mckeemj

Level: Resident

Joined: Sun. Jun 25, 2006

Posts: 867 View posts

Location: San Luis Valley, Colorado ( 2,318m )

#24

Posted by mckeemj: Wed. Aug 7, 2013 - 03:28 PM

I would echo what has been said before that we need to see the layout. Depending upon the way things are connected, it is possible that the inductance of the connections themselves are causing the spikes. Slow diodes and transistors ( in the L293D ) are also possibilities, but, again, the best way to diagnose that is by looking at the exact schematic and how it is connected, physically, in real life.

Sadly, reality is not as simple as theory. There are always more "quirks" to learn about how real systems operate. Then again, I always think that's a great part of the fun.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

Level: Hangaround

Joined: Mon. Mar 5, 2012

Posts: 108 View posts

Location: Turin, Italy

#25

Posted by thexeno: Wed. Aug 7, 2013 - 03:37 PM

I'm sorry, I need to be clear about this topic, again. :)

Here I DON'T want to find how and why disturbances are generated, but ONLY how and why (possibly) the MCU has an unpredictable behaviour under certain disturbances.

The layout is made badly ON PURPOSE, to analyze how disturbances interfere with the system.

Level: Resident

Joined: Tue. Jul 19, 2011

Posts: 708 View posts

#26

Posted by Chuck-Rowst: Wed. Aug 7, 2013 - 03:50 PM

thexeno,

So, to be clear, are you trying to understand how & why the micro (AtMega328P) is "misbehaving"? That is, performing in a manner which is not totally controlled by your program code.

Let me give a real simple example. Suppose I write a program to continuously turn an LED on & off at a precise one second rate at 50% duty cycle. Normally, the program runs perfectly. But under certain conditions (e.g. you hold a cell phone next to the micro, or use an electric drill next to it), the LED blinks erratically, or the duty cycle changes to 35%, or LED is completely off, or completely on, etc.

Using this example, do you want to know what happens inside the AtMega328 that makes the LED exhibit any of these "wrong" operating modes?

I think that's what you are asking.

Level: Hangaround

Joined: Mon. Mar 5, 2012

Posts: 108 View posts

Location: Turin, Italy

#27

Posted by thexeno: Wed. Aug 7, 2013 - 04:24 PM

Chuck-Rowst wrote:

Using this example, do you want to know what happens inside the AtMega328 that makes the LED exhibit any of these "wrong" operating modes?

I think that's what you are asking.

eheh, yep. But for that, Kartman and others has already answered to me.
But who assure to me that is only HW fault? in fact...

...The last and important thing that I wish to undertand is if this could be enhanced by the structure of the firmware, which I have uploaded. Since I use Interrrupts. If the code could be made more "strong" under this point of view.

But for a misterious reason, with at least 8 people answering, the code has been downloaded only once. lol

Level: Resident

Joined: Tue. Jul 19, 2011

Posts: 708 View posts

#28

Posted by Chuck-Rowst: Wed. Aug 7, 2013 - 06:17 PM

thexeno,

There are certainly many ways to make a micro-based system more robust and immune from "disturbances". Most of these involve hardware design. If you don't have robust hardware, there's not much you can do in software to improve robustness. The execution of the software is completely dependent on proper electrical operation of the hardware. Simple as that.

Nevertheless, once you have a robust hardware design. there are certain things you can do with the software to make the overall system even more robust. But these techniques are highly dependent on the specific micro and its hardware structure. These software "braces" may help the system survive minor operational anomalies and hardware "hiccups", but the simple fact is that the execution of the software is entirely dependent on proper operation of the hardware.

I think that's why none of the responders (except me) downloaded your code. The problems you are experiencing are clearly symptoms of classic hardware deficiency problems.

A Golden Rule of Microprocessor Design:
"There is no software without hardware."