Something is killing my ATMEGAs

I am trying to flash a custom board with an ATMEGA328P-AU with a MySensors sketch to read the temperature from a BME280 and send it to a base station. Due to the minimized design, I only have an ICSP header and TX/RX.
I have connected an USBasp (latest firmware from 2011) to the ICSP header and TX to RX of a USB-to-Serial adapter on the same computer (so it gets the ground from the USBasp).
This works fine in the beginning:

  • I can set the fuses with -U lfuse:w:0xe2:m -U hfuse:w:0xd2:m -U efuse:w:0xfe (though I need to use -B1000, don’t know if that is normal when the DIV8 clock divider is in place initially)
  • I can flash (using the Arduino IDE) and run through the MySensors security peronalizer (writes AES and HMAC key to EEPROM)
  • I can flash and run the example sketch from the Bluedot BME280 library and get the temperature.
  • I can flash and run my MySensors sketch with debug enabled. It exchanges encrypted and signed messages with the base station, but cannot read the temperature. I THINK this is because the DEBUG mode doesn’t leave it enough RAM.
  • I tried to flash the same sketch with debug disabled (since RF communications tested working), but now I got
avrdude: verification error, first mismatch at byte 0x0000
         0x00 != 0x0c
avrdude: verification error; content mismatch
avrdude: verification error; content mismatch

From now on. I cannot communicate with the chip anymore. All I get is

~/arduino-1.8.5/hardware/tools/avr/bin/avrdude -C ~/arduino-1.8.5/hardware/tools/avr/etc/avrdude.conf -c usbasp -P usb -p atmega328p -B1000 -v -F 

avrdude: Version 6.3, compiled on Jan 17 2017 at 11:00:16
         Copyright (c) 2000-2005 Brian Dean,
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/home/kay/arduino-1.8.5/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/home/kay/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : usb
         Using Programmer              : usbasp
         Setting bit clk period        : 1000.0
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : usbasp
         Description     : USBasp,

avrdude: set SCK frequency to 1000 Hz
avrdude: error: program enable: target doesn't answer. 1 
avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x988c72
avrdude: Expected signature for ATmega328P is 1E 95 0F

avrdude done.  Thank you.

The device signature stays the same when the programmer is run unconnected.

I have gone through 3 ATMEGAs like this, now. They pretty much all failed roughly at the same step. For the first one, I did not have a pullup for the CS of the SPI radio in place, so I pulled it to HIGH with a jumper cable. This worked, I got through the steps on top. When I thought I was almost finished, I soldered a 10k pullup in place, connected it again, flashed, and the chip was gone.
I thought I maybe damaged something with the jumper wire when D10 went low, so I desoldered the chip and replaced it with a new one. I went through the steps, and when I just wanted to do the supposedly last flash, it died as described above.
I replaced the chip again, and it went essentially exactly like the time before. Only difference between the last flash and the one before was that in flash end-1 debug was disabled and it supposedly ran out of memory (but did not crash, it just read 0°C, send the package and went on) and in the last run, debug was disabled, but uploading failed. So if something was destroyed, it happened during or directly after flash end-1.

ANY idea what could have killed my chips?

Some more info:

  • Radio is an RFM69HCW. Pull-up on CS was in place all the time in try 2 and 3.
  • 3.3k pull-ups (measured) on I2C
  • 2 100nF ceramic caps on the back of the PCB under the chip, with direct connections to both VCC/GND double pairs,
    10uF ceramic and 220uF tantalum close to the chip.
  • 100nF at the radio (also close to the 10uF and the 220uF), 100nF next to the socket of the BME280 module.



Schematic of the PCB? Isn't that a 3.3v radio? Is your USBAsp using 3.3v output levels, and supplying 3.3v?

Yes, it is a 3.3V ISP. That is also why I haven't tested an ArduinoISP yet. No Pro Mini at hand.

Will post schematic tomorrow, on the phone right now.

In what situations does the Arduino IDE actually burn the fuses? I cannot rule out that I selected the wrong board (Pro Mini 8MHz, which expects an external crystal).
If it actually happens when uploading the sketch, I don't understand why I could go through multiple sketches before the new fuses came into effect, though.

Here are the schematics.


In addition, there is a 10k pull-up on the CS pin of the radio. The ATSHA204, respective cap and pullup are not soldered.

So I killed another chip, apparently.
This time, I took a old, trusty Nano clone, used the head to flash the fuses I wanted, unsoldered the chip, soldered it to my project. I also made sure to have my custom board definition with the right fuses selected.
Worked a few times, then blew. Also, I failed to solder old chips to the Nano PCB with the oscillator, in case they just expected an external clock.

Long story short, I measured my USBasp clone thingy and found out that despite being set to 3.3V, all data lines a still 5V ...
This might explain why it worked for a while, until the voltage difference between VCC and data killed something. Damn ...
Can anyone recommend a not too expensive ISP that actually support 3.3V? In contrast to the ATMEGA, my periphery will not survive flashing at 5V.

My USBasp looks like this one, not like the one in the second answer here. The latter looks like this one.

This one seems o have a notably different board layout, most others look like mine.

The original is reasonably priced, but it does not seem to support 3.3V.

Here is the image of horror of VCC, SCK, MOSI of my programmer.

I am also not at all happy about the 750mV amplitude, ~27 kHz oscillations in VCC. 5V are quite stable and the it does not depend on if my T440s runs on battery or power supply, BTW.
It is interesting, though, that the only IC that could be an LDO does not have any cap nearby :slight_smile: