Bootloader verification error

Hello World. I am making my first attempt at an (SMD) Arduino on a breadboard using the internal 8MHz clock by following the instructions from this page. I am seeing unreliable results in both burning the bootloader and in uploading sketches.

Hardware and wiring descriptions will follow below.

Problem 1:

Bootloader appears to correctly write fuses before writing ATmegaBOOT_168_atmega328_pro_8MHz.hex, but then fails verification. Verbose output from burning is attached (20201001_1_BootloaderBurnOutput.txt). Relevant lines are:

avrdude: verification error, first mismatch at byte 0x7f01
         0x00 != 0x93
avrdude: verification error; content mismatch

Despite this, I was able to upload a blink sketch with no error and verify that it works.

Problem 2:

When I attempted to upload a different sketch, I get another similar verification error. Verbose output is attached (20201001_2_SketchUploadOutput.txt)…

avrdude: verification error, first mismatch at byte 0x0000
         0xff != 0x0c
avrdude: verification error; content mismatch

Questions: Was it ok to have some mismatch on the bootloader verification? If not, how can I fix this? Why would the first sketch upload work, but the second one fail?

Problem 3:

It seemed my problem was similar to this post, so I thought I could just re-burn the bootloader. It completed again with a verification error (see 20201001_3_BootloaderBurnOutput.txt)

Now when I attempt to upload a sketch, I’m getting a no response error. Full error output is in 20201001_4_SketchUploadOutput.txt

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x7f

I am aware that you can get this error if the TX/RX connections are bad. I tried switching those lines but got the same result.

Question: Have I bricked my chip?

Hardware and Wiring Description:

  1. I have the target ATMEGA328P-AU (SMD 32QFP package) soldered onto a custom PCB that breaks out the relevant pins to an ICSP header and a SER header.

  2. For burning the bootloader, I am using an Arduino Uno per instructions. There is a 33 uF cap between RESET and GND on the Uno. Connections are as follows (Uno - target):
    D10 - RESET
    D11 - MOSI
    D12 - MISO
    D13 - SCK
    5V - 5V
    GND - GND

  3. For uploading sketches, I am using this Sparkfun FTDI breakout board. Connections are as follows (FTDI - target):
    TX - RX
    RX - TX
    VCC - 5V
    GND - GND

Note that there is a 10k resistor between RESET and 5V on the target.

20201001_1_BootloaderBurnOutput.txt (9.27 KB)

20201001_2_SketchUploadOutput.txt (29.9 KB)

20201001_3_BootloaderBurnOutput.txt (9.27 KB)

20201001_4_SketchUploadOutput.txt (17.3 KB)

UPDATE: I believe I tracked the problem down to poor connections during burning and/or sketch uploading. I dont know exactly how this led to the issues, but the short version is basically not to have janky connections for programming.

Some details that might save someone out there some grief…

I experienced much of the problems described above when I just had jumper wires pushed through the ICSP and SER programming “headers” on the target board. These headers were simply plated through-holes on the PCB – my hope was that the bootloader burning and sketch uploads were pretty much a one-time thing and didnt want to bother with populating the board with better connectors.

The way I had it, these connections can work themselves loose, so I would just press down on them during data transfer, thinking that would be good enough. Once I soldered the wires down, everything worked as expected.

I did, however, need to replace the target chip. Using Nick Gammon’s Atmega_board_detector, I was able to see that all memory locations were stuck at 0xFF and would not change under any of the procedures described in the last post.

Lesson learned!