# ATmega328P firmware flashing interrupted - is it fixable?

I am working on some PCB with an ATmega328P on it. I use a Pogo connector because we have to program and test the PCB outside.

I program with usbTiny, (mosi/miso/rest/clk/power)

Anyway, many times during programming I move a little bit which disturbs the Pogo pin contacts and get a verification error. Then I start again and flash it successfully.

But sometimes, after a movement and a mismatch on verification, I can not flash it any more, like now.

I get :

avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.



I got extremely tired from manufacturing again and again :( and I am sure the chip is still OK. This will probably happen again.

I have read that there are ways to save it, like serial programming or oscillator.

How exactly can I do this with serial?

VERBOS:

       Using Port                    : usb
Using Programmer              : usbtiny
avrdude: usbdev_open(): Found USBtinyISP, bus:device: 020:013
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 : USBtiny
avrdude: programmer operation not supported

avrdude: Using SCK period of 10 usec
avrdude: initialization failed, rc=-1


It seems likely that you have inadvertently changes the fuses to one of:

• Disable /RESET
• Different clock speed or clock source
• Disable SPI programming

To recover this you need to use a "high-voltage" programmer that involves holding /RESET at +12V whilst specific sequences of commands are sent through most of the other pins. This may be difficult with your "pogo pin" arrangement.

It may even be impossible if putting 12V into /RESET damages other circuitry (eg. if you have a pull-up resistor that would bleed 12V into the 5V line).

I have a post about using another Arduino to do high-voltage programming here.

You can see that there are a lot of wires, and it may not be practical to do what with pogo pins.

You can also use an AVR Dragon board to provide the necessary signals and pin-outs.

However this would require that you either remove the chip and place it inside the programmer, or run something like 18 wires to the board, similar to the earlier solution.

I suggest, whilst testing, that you solder on a 6-pin header suitable for doing your SPI programming. That will eliminate the pogo pins, and give you a reliable contact for programming. Once you have debugged it the production models won't need that.

You could use my chip detector sketch which would help show if the chip is unresponsive, or has merely had some fuses changed (eg. clock source).

Example output from the sketch:

Atmega chip detector.
Entered programming mode OK.
Signature = 1E 95 0F
Processor = ATmega328P
Flash memory size = 32768
LFuse = FF
HFuse = DE
EFuse = FD
Lock byte = CF
EEPROM preserved through erase: No
Watchdog timer always on: No
Bootloader is 512 bytes starting at 7E00

7E00: 11 24 84 B7 14 BE 81 FF E6 D0 85 E0 80 93 81 00
7E10: 82 E0 80 93 C0 00 88 E1 80 93 C1 00 86 E0 80 93
...
7FE0: E7 DF 80 32 09 F0 F7 DF 84 E1 DA CF 1F 93 18 2F
7FF0: DF DF 11 50 E9 F7 F4 DF 1F 91 08 95 FF FF FF FF

MD5 sum of bootloader = 0F 02 31 72 95 C8 F7 FD 1B B7 07 17 85 A5 66 87

First 256 bytes of program memory:

0: 0C 94 35 00 0C 94 5D 00 0C 94 5D 00 0C 94 5D 00
10: 0C 94 5D 00 0C 94 5D 00 0C 94 5D 00 0C 94 5D 00
20: 0C 94 5D 00 0C 94 5D 00 0C 94 5D 00 0C 94 5D 00
30: 0C 94 5D 00 0C 94 5D 00 0C 94 5D 00 0C 94 5D 00
40: 0C 94 80 03 0C 94 5D 00 0C 94 C9 00 0C 94 5D 00
50: 0C 94 5D 00 0C 94 5D 00 0C 94 5D 00 0C 94 5D 00
60: 0C 94 5D 00 0C 94 5D 00 E5 01 11 24 1F BE CF EF
70: D8 E0 DE BF CD BF 11 E0 A0 E0 B1 E0 E0 E9 F8 E0
80: 02 C0 05 90 0D 92 A2 32 B1 07 D9 F7 11 E0 A2 E2
90: B1 E0 01 C0 1D 92 A2 3C B1 07 E1 F7 10 E0 CA E6
A0: D0 E0 04 C0 22 97 FE 01 0E 94 42 04 C8 36 D1 07
B0: C9 F7 0E 94 1F 02 0C 94 46 04 0C 94 00 00 08 95
C0: FF 92 0F 93 1F 93 06 EA 11 E0 C8 01 40 E0 52 EC
D0: 61 E0 70 E0 0E 94 FA 00 C8 01 0E 94 44 03 C8 01
E0: 60 E0 71 E0 0E 94 75 03 91 E2 F9 2E E0 E0 F0 E0
F0: F0 92 57 00 E4 91 C8 01 6E 2F 40 E1 50 E0 0E 94


Source for sketch on GitHub - in "Atmega_Board_Detector" folder.

• Thank you Nick, seems to me I am not going to be able to do so because I have very sensitive parts on this pcb . What about external oscillator ? I will have to find a way to remove the chip, is it possible without special tools? – Curnelious Feb 19 '17 at 21:06
• It depends on the package type (SMD or DIP). However both would be very difficult to remove once soldered on. If surface mounted you might have a chance, but you would probably need special tools. I believe there is a product that can be used to remove SMD chips (it mixes with the solder and lowers its melting point). Would it be possible for you to use a chip socket while testing? That might be the most practical solution. – Nick Gammon Feb 20 '17 at 4:57
• What about external oscillator? - You could use my chip detector sketch which would help show if the chip is unresponsive, or has merely had some fuses changed (eg. clock source). – Nick Gammon Feb 20 '17 at 5:08
• It would be nice if you'd add the relevant parts of your forum post to your answer. – try-catch-finally Aug 13 '17 at 16:25
• The post is a bit long (and the source is a bit long) but I've added more detail to the reply rather than leave it in a comment. – Nick Gammon Aug 13 '17 at 21:53