Atmel 89S52 Microcontroller Problem

Sounds like you're either getting noise from the motor on your power lines, or else the motor load is pulling down the power line on the micro.

Is the microcontroller properly bypassed/decoupled? Are you using high grade ceramic caps in the .01 to .1u range?

Can you monitor the micro supply pins with an o'scope?

I did all possible to filter the power and also use isolated batteries separately for uC and H-bridge. Link to H-Bridge is weal 10k resistance driving signal transistors that can not affect the uC. Something else is doing it. Perhaps signal may begetting picked through crystal oscillator pint and may be causing some problem. There is one switch that is used to disconnect power to uC and perhaps this may be vibrating when motors move. I will find out if that is the source of problem. I can record signals, including power lines to trace the fault so will start doing it tomorrow. Some dry solder may also be a cause of problem. Let me explore all possibilities. Soldering was done by students so it is somewhat clumsy.

Sounds like (better) decoupling is needed to me. If bhankiii's fix doesn't work, can you optoisolate the H-bridge from the micro, and completely separate the supplies?

I agree with BlankII

According to the specs the 89S52 will operate between 4.0 and 5.5v while the 89c2051 is recommended to operate at 5 V+ or - 20 % (= 4 to 6V) and the absolute Maximum is 6.6V.

Your new Microcontroller has a narrower tolerance to power supply fluctuations... about half 5V +10% or -20% .

Most TTL Logic will operate as low as 3.7V before going into the indeterminate range. Even though the minimum voltage is listed as the same, the extra memory in the chip is probably loading down the power supply a bit more then the old one. This would make it more sensitive to any loading from the motors.

Possible solutions:

• Put current limiting resistor or choke in series with motor, unfortunately this will slightly reduce starting, and operating speed .
• install a larger starting capacitor for the motor.
• Get a better power supply (faster response). The new chip is running faster. To reset it requires a surge for two cycles at 33MHZ as opposed to 24Mhz in the older chip
• have separate power supplies for the motor and logic

I used diode to isolate power and keep charge on 2000uF capacitors with 0.1uF HF decouple capacitors. This did some improvement but problem still persisted. It fails after 4-5 commands in place of one command. uC resets and some times goes into some close look. It looks that internal SRAM data is also getting affected. I will keep the uC board a bit away from wireless transceiver board. I suspect RF may be affecting the 22MHz uC clock. 89S52 is static uC so change in frequency can not affect the performance as long as code decode cycle is not affected badly.

The best way to protect from RF is a grounded shield.

If that doesn't help, the problem is with the power. I would try increasing the starting capacitor in parallel with the motor first. If that doesn't work go with the current limiting choke or resistor in series with the motor.

Current to motors right now is limited by the motor coil resistance / inductance and some drop in the transistors of the H-bridge. Power is through batteries of high current capacity. Drop in battery voltage is only 0.5V in 12V when motors run continuously. Let me check the ground loop if that is forming some voltage somewhere.

its eventually disturbed by toy motor which is sparkling when runing. change a motor of unbrush one. or shield the motor itself.

for the mpu, use a zener of 5.1v at 40pin with a resistor of 30--51ohm series to power.

output pins link zener as well then to H driver.

split ground wire and H ground and let them connect at power terminal.

add a capacitor across onto motor between H. 4small capacitors parallel with H. about 100--500pf.

thats absolutly ok.

why you use s52? its only very very simple driver!! you waste almost of their pins!

which port are you using?

dont forget to add a up pull resistor at p0 port

You have a very good point and let me see about this seriously.

Shyam,

I have similar problems driving a dc motor with a microcontroller. The brushes on the motor are probably giving you rf interference. A capacitor alone will probably not give adequate filtering. Try an L-C filter with a ferrite for the L.

Stepper motors are a little more expensive, but free of brush problems.

Good luck,

Dave

Hi LG Dave

Humm. All good answers are pointing to motors finally. DC- Brushless motors perhaps is the ideal choice. I am surprised with the performance of the ADF7020 wireless transceiver, as this one is not in trouble. Only AT89S52 is in trouble and getting reset. Even with isolated DC power, it was getting reset. It is not just getting rest but its internal memory is also losing data. Hence, it is picking up noise right in its core thru plastic casing. That is real bad thing. I think this uC is not a robust is design. I will change this uC to another type and in similar condition will like to evaluate the performance.

Shyam,

You probably won't find any more robust uC than the Atmel ones. And you probably won't find anything more frustrating that dealing with interference from a nearby strong RF field, especially when it is connected electrically. ( a floating ground may be more frustrating - but that is another discussion)

I suggest verifying the following points:

1. All pins of the uC should either be grounded or have as low an impedence as possible. Make sure unused port pins haven't been forgotten. The AT89S52 is a low power part and more susceptible due the inherently high impedences.

2. All the filtering and protection devices rely on a good ground. Do you have a plane or some heavy ground busses?

3. Shielding is a ghastly business - but you may want to try some temporary shielding just to verify the conduction path for the RF.

4. I suspect that your final solution will involve filtering using ferrites and caps.

Experiment to find the right values.

Dave

Dear LG Deve

I have another uC from Renesas which drives wireless and works fine. Only Atmel 89S52 has problem. Did not find such great problem with 89C2051. Most of the wireless transceivers prefer Microchip uC to Atmel. Almost all have experienced some problem with Atmel uC.

I will reduces the operating frequency from 22MHz to 11MHz to see if that makes some difference. I have already placed filters for the motors. Tomorrow I will test this change. i need to get to the bottom of all this.

I am using 89S52 in my ST1006 and ST2006 waveform generators where memory is scanned at 10MHz rate and that did not have much problem. I did place very tight shielding there and both layers are shielded as close as 3mil from conductors.

No this board that is for students was developed by another person and he did not do good shielding and earth line is also thin to 1mm. I am not drawing any current from this board. Total current drawn is <10mA from all ports. I also placed pull up resistors but that did not help and only caused loss of current. Other than data port, all other ports already have internal pull up scheme. Chip normally draws 30mA at 11MHz and perhaps 50mA at 22MHz.

Just a thought - if you can set up two systems - one working, just driving a motor, and the other one being your suspect system, you could see if there is any RF interaction by operating the motor/drive at varying distances from your suspect system (with no electrical connections between the two).

Dear John DG

You have a point. I must try to see how fat this problem reaches. It is indeed a very good idea. I did EMP tests on chips long ago and I will try this RF range test as well. I think RF must have reduced now as I have placed capacitors across the motor power points. It will kill the electrical current impulses through ceramic caps 0.1uF very easily. I have seen such arrangement in one toy car which was RF driven from remote.

I did not see a mention of the H-bridge type .. if its a darlington design maybe freewheeling diodes across the transistors would help, if its mosfet it is fine of course.

I find PICs are the best uC I have come across for noise immunity. I use 18f's in almost every design I do now.

Hi Stoney

I am using 2N3055 transistors and diode I think were not placed. Let me add them now to see if inductive current surges come down and help.

Good point.

I inserted diodes but they killed the batteries in no tie I a using AA non-chargeable batteries and excess charge injected heated the batteries and they were dead in just 10-20 operation in less than few minutes. Perhaps diodes may work fine with other DC power sources. I am going to place Lead Acid batteries but they are very heavy for small robot and may cause problem in motion control.

I changed the uC to 89C2051 and this one works fine.

Sorry if you've already answered this (and I missed it), but did you try another 89S52 (maybe from a different batch)?

Dear John DG

I usually buy parts in bulk so have many from one batch only. They are working in normal operation in my other designs and in this particular application I found problem.

89S52 is highly voltage sensitive design 4.5V to 5.5V operating limits. 89C2051 is 2.7V to 6V operating range and works fine even at 2V. This 89C2051 is not affected by small surges due to motor currents and draws 1/3 power. I need to take care in future and have to test all Atmel ICs now for voltage surges in power supply and their operating dynamic range. I will also do some tests using EMP. I am also going to look at other uC to let me know which one has greater survival strength in tough environment.

One of my trained engineer did report that Atmel uCs were often failing in industrial environment, while he found no such problem with PIC series. Hitachi H8 and other series also look good and are now manufactured under name Renesas. I did use Intel 8751 uCs earlier and 8085 uP. 8085 did have this problem of greater sensitivity to noise. However it was Rad-hard so I did use in some applications.

I will try H8 Tiny series also as they look robust. I find Renesas information over crowded and not properly arranged. However, they do have open information system and C compiler all for download. Chips are SMD so another problem and need boot down-loader.

the diodes should make no difference to the batterys, they only conduct on inductive spikes. If the batterys are heating up then maybe you have a logic or design fault and the h-bridge is acting as short circuit due to the top and bottom being on.

perhaps a read-modify-write problem on the port .. not overly familiar with Atmel parts but I would think they are similar to the PICs.

10k should be fine off the port pin though so the port is not heavily loaded.

what sort of current is this motor drawing ?

Dear Stoney

I have already changed the uC to AT89C2051 which did a better job. Some pins of this uC were not driving as others were on same port number. As per design they are same type.

I also changed battery from disposable to Lead Acid 2.2A 12V version which I could get with 1kg weight. After all these changes, robot moved as was planned. I converted the code for new uC.

ADS7020 wireless transceiver is also working fine.

I am waiting for 12V 1.3A-hour battery having 500g weight to make more robots now. For a while I will use AT89C2051 and AT89C4051 uCs only.

I will also hunt for more robust uC now. I am bit scared of AT89S52 for noisy environment. I think something wrong in design of the chip itself in terms of robustness to noise. I will also make few highly shielded board for AT89S52 to see if they can be used at all. What makes it to fail I am yet to know. I only have crude idea that noise triggers it down while other uCs are not affected at all.

I had a similar experience in the past, be very careful of the ground on the processor. it may be come elevated and reduce the actual VCC ion the chip. also check the back emf from the motors to see if they are driving the supply low..

this may be due to power supply because when motor starts it puts load on supply and glitches in supply fall blow regulation limits the other cause could be sparking in motor comutator . put a smothing capacitor of sufficient caoicity near motor driver and a 0.1uf milar capacitor across motor supply terminals.this will solve your problem and by the way do not put load on port use higher resistence.

Finally this became a comparative study of the reliability of the two types of Atmel uCs, AT89C2051 and AT89S52 and both working at 22MHz and 11MHz frequencies. AT89C2051 wins over the AT89S52 in terms of reliability.

Yes, I did make all those suggested changes like placing diodes and filters across H-bridge motor driver circuit and power supply decoupling caps. Peak current from motors easily exceeded 3A in each motor momentarily. Batteries used were powerful enough to deliver 16A peak current without much drop in voltage. There is step down voltage regulator for the uCs and battery voltage is 12V. Even if battery drops to 9V, the regulator will take care of the power glitch.

I think it is the design problem and these two uCs differ in design considerably and AT89S52 is not so robust design.