Resetting fuses on bricked ATmega328p soldered to PCB

[drdelos]

Can anyone help me with resetting the fuses on an ATmega328P-MMHR 1 (28-pin VQFN) which I think I’m bricking when I try to upload code to my watch PCB. I have been told I might be screwing up the fuse bits somehow and I'm looking for help to reset them.

I'm running an ATmega328P-MMHR 1 (28-pin VQFN) with an M41T62 (8 pin LCC) real time clock, powered by a CR2016 coin battery. It displays the time and day of the week on multiplexed LEDs.

I usually upload code using Programmer via a UNO using ICSP with pogo pins pressed onto six exposed pads (which I sometimes bulk up with solder).
The connections, from Atmega -> UNO, are:

• GND -> GND
• RST -> D10
• MOSI -> D11
• SCK -> D13
• VCC -> 3.3V
• MISO -> D12

However, during long code development phases, I will solder the wires to the pads:

One minute I'll be uploading with pogo pins fine (bricking hasn't happened while the connections were soldered) and the next, it gives me this error message:

Using Port : /dev/cu.usbmodem11101
Using Programmer : stk500v1
Overriding Baud Rate : 19200
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 : STK500
Description : Atmel STK500 Version 1.x firmware
Hardware Version: 2
Firmware Version: 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x000000 (retrying)
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x000000 (retrying)
An error occurred while uploading the sketch
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override this check.
avrdude done. Thank you.

And I can't upload anything after that.

I tried using Nick Gammon's bootloader to detect the chip but got the following output:

Attempting to enter ICSP programming mode ......................................................
Failed to enter programming mode. Double-check wiring!
Type 'C' when ready to continue with another chip ...

I also tried using Gammon's method and the Atmega_Hex_Uploader sketch to check and modify fuses using a microSD card breakout with suggested connections:

• D4 (SCK)
• D5 (SS) (reset)
• D6 (MISO)
• D7 (MOSI)
• +5V > 5V (red)
• Gnd > GND (blue)
  (though I'm using 3.3V on the UNO)

but got this error:

Attempting to enter ICSP programming mode ......................................................
Failed to enter programming mode. Double-check wiring!
Halted.
Programming mode off.

This post uses an external clock via a Nano to change the fuses:
"Power the bricked chip by the 5V and GND from the Arduino Nano, and hook up the D6 pin to the PB6 (XTAL1) pin of the bricked Atmega328p."

I tried it with the following connections:

• 5V (or 3.3V)
• GND
• Nano's D6 to Atmega's PB6 (XTAL1), i.e,
  
  

but got the following:

     Using Port                    : /dev/cu.usbmodem1101
     Using Programmer              : stk500v1
     Overriding Baud Rate          : 19200

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00

Really hoping someone can help me unbrick my Atmegas, because I'm running out of them and can't get any more until April next year

[pylon]

My guess is you set the fuses to use a crystal for the clock signal instead of the internal 8MHz clock. So it's critical to use the correct board setting if you upload by programmer.

The Nano fix is to provide a clock signal to the Atmega, but that post is for a 5V target system. You must not put the Nano's 5V signal to the XTAL1 input of a 3.3V ATmega. Theoretically the programming setup is already an over-voltage but the SPI pins are probably less sensitive than the super low current crystal inputs. So use a 3.3V system to provide the crystal emulation signal.

[drdelos]

Thanks. I tried the Nano method but using a UNO, with the 3.3Vs connected, and D6 connected to the XTAL1 input of the ATmega. Error as above. Would you have expected this to work, or are you suggesting I use something like an Arduino Pro Mini 3.3V/8MHz?

[markd833]

@drdelos

I tried the Nano method but using a UNO

An UNO is a 5v board with 5v outputs. I would take on board the advice from @pylon:

@pylon

So use a 3.3V system to provide the crystal emulation signal.

[pylon]

@drdelos

Would you have expected this to work, or are you suggesting I use something like an Arduino Pro Mini 3.3V/8MHz?

Yes, something like this. The problem is that you already might have fried the XTAL1 pin by connecting it to 5V while running on 3.3V. That's not easy to check if you have wrong fuses settings.