AVR ports malfunction

[guerra]

Perhaps the most serious of all hardware issues that we are facing right now is the problem of malfunction of the AVR ports. Although it is still unknown how many of the reported issues are caused by this problem, recently many teams have noticed strange behaviors that match the symptoms of malfunctioning AVR ports.

Typically either or both wheels stop completely or show very jerky movements as if its spinning velocity was disturbed by some kind of noise. This is the only noticeable symptom under normal usage conditions. The diagnostic of the problem is clear if the output of the pins are examined with the aid of an oscilloscope while the controller board attached to the programmer/debugger board executes some commanded motion (e.g. fw,14 for fast foward motion). See this YouTube video.

Robots with AVR port malfunction, despite the obviously noticeable wheel spinning problem might pass all of the following tests -- note that not passing any of the tests below does not mean the robot does not have AVR port malfunction, it might just mean it has a more complex combination of different problems:

• ARM programming is OK, program checks and runs smoothly and console debug shows no problem at all.
• AVR programming is also OK, program checks and runs smoothly, with console debug also fine.
• ARM might listen fine to infrared commands, and respond appropriately.
• AVR and ARM communicate just find with each other through the SPI port.
• Connectors show no mechanical problem, there are no short-circuits in the boards, the solders are fine.

My guess is that reverse current from the motors is traveling back to the processor and damaging it. This means that in order to fix the
robots we would need to:

• Replace the AVR processor -- difficult and delicate work, but possible
• Re-design the bottom board adding some diodes in series to each motor connector in order to avoid reverse flow of current.

For your reference, if you look at the row of 8 LEDs in the programmer/debugger board, from left to right their corresponding jumpers are connected to the following pins of the AVR, respectively: PA0 (left-most),PA1,PA2,PA3,PA7,PB0,PB1,PB2 (right-most). The pins PA0,PA1,PA2,PA3 drive the left motor while the pins PA7,PB0,PB1,PB2 drive the right motor. See attached images. The AVR schematic diagram shows the name of the pins as observed in the bottom of the controller board if held with the IR sensor facing down.

[msimoes]

Hi all,

We have performed tests using an oscilloscope, as suggested by Guerra. We have 10 robots. Six controller boards simply send no current as output. No led state changes and no current is detected in oscilloscope. We guess that on these 6 boards, AVR would be not working at all. Although, we can successfully record ARM and AVR firmware on all boards. When we have tested these boards, robots wheels don't move.

On other 3 boards, we have detected a behavior similar to that one showed by Guerra in the video. Some pins present noisy signal with lower frequency than normal ones or other anomalies. During these tests, we see  jerking moves on wheels, too.

Only one board presents a normal behavior. All pins generate a normal output and wheels work fine.

The later 4 boards presents the supposed reverse current from the motors on almost all pins. The worst news is that Guerra is right to say that this reverse current can damage AVR or AVR pins. One of our malfunctioning boards (one of the four that present jerking moves on the wheels), stopped working during the tests. Suddenly, it had the same behavior described for the 6 earlier boards. We have tried to record firmwares again and it was successful. But the board still doesn't work at all. So, now we have 7 non-working boards.

We guess that using the robots with the current design will lead all robots to become damaged on a near future. That way we have a high probability that no team has working robots when we arrive at Singapore next year. If we really want to continue Mixed Reality in RoboCup it is very important that all teams who own robots performs the tests suggested by Guerra and report the results here. It is important also that all teams try to solve this AVR malfunctioning problem and share the solutions here, so we would have a chance to see many working robots and a good competition next year.

Best Regards,
Marco
on behalf of BahiaMR team.

[Soenke]

Hi all!

i've designed a new head-pcb for the Eco-Be robots. It was a project to replace the old version with a low-cost pcb. The new design has only one Atmage 168 µC and is fully compatible with the system. In order to avoid the port-damage of the µC, i've added protection diodes to protect the ports. The diodes should prevent high voltages of the stepper motor inductors. The source code is fully ported to the atmega 168 and the main functions are tested. We try to test the function of the diodes as soon as posible. I hope this will help.

Best Regards,

Sönke (WF Wolves)

[Soenke]

Hi all! Now we've soldered the new version of the headboard with the protection diodes. Here is an image of the signals:


We will start a stress-test now.

Best Regards

Sönke

[msimoes]

Hello Sönke,

Please let us know the stress-tests results when they are finished. And, if it is confirmed that this new board solves this problem, please turn the project available for all teams.

Best Regards,
Marco Simões

[lordofnaz]

New solution for robots problem is here:

A3901  chip from Allegro Microsystems Inc.
Datasheet link : http://www.allegromicro.com/en/Products/Part_Numbers/3901/3901.pdf
Digikey link : http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=620-1159-1-ND
This chip is a very small , power full and cheap stepper motor driver with internal diodes  and  transistors.
We can place this chip on bottom board of robot between AVR and stepper motor and solve all problems.

mahdi dadashi
mechatronic research lab (MRL)

[jgrimaldo]

Great,

So simple, yet such amazing results...

Could you tell if you changed the firmware?

[guerra]

Thanks for pointing the chip A3901 Mahdi. I guess the bottom board could be easily redesigned to accommodate it. Anyone?

[msimoes]

Hello Guerra and all,

We are working on this problem since Graz and we will try to use this chip as a possible solution. As soon as we get any result we will let you know.

Best Regards,
Marco

[lordofnaz]

hello
tanks for your attention.
we can place this chip between avr and steppers without any change in firmware.
i am working on new bottom board with A3901 driver and max1555 (with leds) for charging robots without any charger , only with USB power.

[guerra]

Charging directly from USB is a great idea! Please also consider about making logical data connections. Remember that pins 30 and 31 of the bottom connector are already connected to DDM and DDP signals for USB communication with the ARM microcontroller.

[ARMIN]

Hi,

As mahdi said before fortunately he designed a new mid-board based on A3901 stepper motor driver and we implemented this board and tested it. I didn't see any malfunction yet and I think it works well. This is the first pcb of this middle board and just I put the A3901 on it. The pcb board is attached to this post and it only deals with the reverse current to AVR. You can put it between the body and control board and be sure that the AVR never fail again.

Now, we are working on the new board that besides the A3901 uses the Max1555 to charge the robots by USB without unplug the control board. I will release it as soon as.

Bests,
Armin

[Vahid]

Hi Rodrigo,

I attached the pdf file in which consist of both mid-boards designed. In the old one, we just consider the motor driver to prevention of reverse current to AVR. We have tested it and I think it works well. About the new mid-board we consider the charger besides the motor driver as we could charge the batteries by USB without unplug the control board. But we didn't assemble it yet. We hope that it will work well same as the old mid-board but we should test it.

Best Regards,
Vahid