atmega32 RIP

Hello Jamie,

Whew, with that subject line I thought they had called of that series.

As usual, it depends :-)

If you have a VCC line running parallel to motor wires all it takes is a few volts induced and that puts VCC above abs max for a wee moment .... bzzzt. With enough C it is less likely to happen but it could still hit port pins where there won't be a C.

Much more common in these situations are ground loops and conductive hits. IOW a direct hit. All this is very difficult to measure because you never knows what part of a spike is actually there and what part of it was is leaked into the scope probe and set-up and isn't there in reality.

When a client calls me with this kind of scenario I usually have to come out because it's nearly impossible to guesstimate what's going on. But think about some of these measures:

a. Enough decoupling caps? Make sure there is a low ESR electrolytic besides the usual 0.1uF ceramics.

b. Do the electronics have one common ground plane? If not, things can get seriously out of hand. Is it nicely bolted down?

c. Can you add ferrite beads? At least for supply lines of the uC?

d. Can you add chokes or big ferrite toroids to the motor? Tell us what kind of motors these are and what controls them (half-bridges? relays?).

e. Ports: Can you slow the signals down by running through RC lowpasses? If the uC doesn't have Schmitt inputs like some of the MSP430 have then you'd have to add Schmitt buffers or inverters.

Atmel also had about a years worth of bad silicon too with the AT Mega32s and 128s. If the date code of that part is somewhere in 2004 it might be because of that. This would be especially if you are running them over about 10 MHz. One problem they had is that they would run erratically. LPM instructions, sometimes EEPROM would be bad, sometimes they might reset themselves, etc.

Of course, it might be something completely different. boB

Hi guys,

The motors and electronics are in a big heavy aluminum box and the data-wires are running in parallel to the battery wires in some places.

I think the best solution may be to ground the whole box and then shield the data cables and connect the shield to the box. Would this be a good solution?

cheers, Jamie

Where can i get more info on that? I searched atmel's site and found nothing but we are having some unexplained problems in one product.

Thank you.

Hello Jamie,

Shielding does help. So do common mode chokes, like a #77 material toroid slipped over the whole data cable (_not_ each individual wire) at each end. If you can, loop the data cable a few times through those toroids. Differential data lines also help but that often isn't in the cards because there aren't enough port pins or board space, or because the layout is already cast in stone.

Try it and post back for more ideas if that doesn't do the trick. On a wheelchair you need to also test for margins. It would be dangerous if it barely works, then someone actually uses it and the controls jam.

I soldered on a new atmega32 and tested it again and it works fine with no shielding added (no TWI packets lost while motors are running) So I guess the atmega just died coincidentally right when I added the cables. Damn Murphy's law! :)

cheers, Jamie

Hello Jamie,

However, consider the possibility that it's running close to the edge. Substrate diodes can take only so much. On one batch it may be more, on another a little less.

Another area to check is whether or not the power regulator to the uC is always stable when a motor runs. I have seen LDO regulators do some weird stuff when there was noise on the input rail, mostly brief bursts of oscillation.

problems in one product.

I'm interested, too. I had AtMega8 problems with Atmel's own AES encrypted bootloader off their website. Sometimes the Atmega8 would become corrupted during normal operation; you could still update firmware with the bootloader, but the program would not run (xtal was running). Found no explanation for this so far.

SioL

this so far.

Additional explanation: "Corruption" was probably in the bootloader code, while it did acknowledge every byte received the code probably wasn't properly programmed into the application flash, the chip needed to be reflashed completely to get it back to life. It happened rarely so its a pain to troubleshoot.

The fuses were set to prevent auto-writing to bootloader section.