ATMega16 high death rate.

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I sent a customer 200 chips for one production batch.
Usually I will program them before sending them, but due to time shortage we agreed they program them after building the board. We did incorporate a JTAG connector in the design, and my customer have reprogrammed before for testing and other purposes. So I know the interface works, so does my customer.

After building those boards close to 30 of them were not programmable! The ususal things were tried to make sure it was not their JtagII, it's flex cable or anything like that.

I got 3 of those boards sent to me. I removed the AtMega16 chips (DIP) using a desoldering pump and put them on "my" (identical) board that has a ZIF socket. No programming possible. The Xtal oscillator runs. I tried programming the chips using ISP on STK500 and same result.

At the same failure rate we'll end up with over 100 dead boards before christmas, so any suggestions are very welcome.

The chips are:ATMEGA16L 8PU 0835K.
Lot info on bottom side: 8G4736-35565O 1-P0835 83

Einar Sjaavik

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Potential difference kills efficiently.

I don't know what kind of setup you are using, but normally an ungrounded PC case (ground) has half of the mains voltage because of filtering capacitors inside the power supply. Not much current available, but voltage is enough to kill devices.

So first make sure the PC is grounded. Even if it is not, disconnect all cables from the AVR board you are programming before connecting the ISP cable, and only then plug in the power for AVR board, and possibly other cables, but make sure it does not burn the other connectors then.

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Too high speed on the programming interface? Perhaps fuses are being incorrectly set and the chips go semi-dead? This is often a problem with SPI programming, not so much with JTAG though.
Have you tried resurrecting them with high-voltage programming?

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

einar wrote:
I tried programming the chips using ISP on STK500 and same result.

But why you not try HV-Programming?

Only if HV-programming fails also, you are sure, that it was defective.

E.g. I tried an ATMega323 with SPI-programming at 16MHz, but it was only rated for 8MHz.
Then SPI-programming was no longer possible.

But after HV-programming it was alive again and SPI-programming was possible again (at 8MHz).

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also a suspect is the soldering setup. Everything needs to be at the same potential, ie. PCB, device, soldering iron, solder (in your case the soldering equipment) or the device dies. Too much heat is another worry.

If you think education is expensive, try ignorance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your response guys!

I will try the HV programming.

It may be bad soldering practice, but it is done by a company that have survived doing board production in Norway for some years. And I cannot believe they would survive in our time and market unless they follow proper ESD and soldering procedures. But who knows?

Einar Sjaavik

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I notice that they are the L version (8MHz), are you trying to run them too fast? What VCC are the boards running at?

..clutching at straws here..

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the target they are run at 3.6865MHz
On the STK500 it's the same.

I just tried HV programming and same result: no read, no write.

But different behaviour on 3 devices.
One of them will lock up the connection to STK500, but only after attempt to read fuses (or lockbits). The green LED near the VTARGET jumper will extinguish when (and after) trying to read.

Before and after trying these 3 devices I tried another device that came right out of the package (same batch). Before trying the other 3 it was OK. After it is not readable in PP mode.

This STK500 is very old and have been subject to some abuse I must admit. So I'll make 2 new jumper cables for parallel programming and check it over. Or buy a new one. I will also try some devices from a previous batch of ATMEGA16's that I have for my own projects.

One strange observation: With the presumably good chip I can read the fuses if and only if I select ISP mode even though the jumpers and cables are set up for PP mode!?

So for the moment I'll assume the inability to HV program may be on the STK500 or its jumper cables or socket.

One solution is to preprogram and test all the IC's in a target board with a ZIF socket. Then at least I'll get to know if chips fail after being programmed and functionally tested. Since my dear customer is not crying to get parts yesterday at the moment I'll probably do just that.

Einar Sjaavik