Burning/reburning bootloader to Arduino Uno/ATmega328p-au

Projects Programming
1

Hi
I ordered a custom made pcb and soldered among other components an ATmega328p-au (solder joints are looking good) and tried to burn the Arduino bootloader on it using my Arduino Uno and the example sketch in the Arduino IDE. Which didn't work.
I got the following error messages:

C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.33.0_x86__mdqgnx93n4wtt\hardware\tools\avr/bin/avrdude -CC:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.33.0_x86__mdqgnx93n4wtt\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -cstk500v1 -PCOM3 -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xDE:m -Ulfuse:w:0xFF:m 

avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.33.0_x86__mdqgnx93n4wtt\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : COM3
         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)

Error while burning bootloader.
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 if I apply pressure to the jumperwire / board connections:

avrdude: AVR device initialized and ready to accept instructions

Error while burning bootloader.
Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x111131
avrdude: Expected signature for ATmega328P is 1E 95 0F
         Double check chip, or use -F to override this check.

avrdude done.  Thank you.

So I tried to use my Arduino Mega 2560. It didn't worked either. And yes I changed to code to use the pins 51, 50, 52.

#define USE_OLD_STYLE_WIRING

#ifdef USE_OLD_STYLE_WIRING

#define PIN_MOSI	50
#define PIN_MISO	51
#define PIN_SCK   	52

I expected my PCB design to be faulty. In order to test my theory I tried to reburn the bootloader on my Arduino Uno using the Arduino Mega, but this didn't worked either.

Mega > Uno
Pin 51 > 11
Pin 50 > 12
Pin 52 > 13
Pin 10 > Reset
Pin 5V > 5V
*Pin GND >GND *

This leads me to the conclusion that I am doing something wrong during the upload.
I mean my design could still be faulty but yeah xD.....

I got the following error message:

avrdude: AVR device initialized and ready to accept instructions

Reading | Error while burning bootloader.
################################################## | 100% 0.02s

avrdude: Device signature = 0x00ff00
avrdude: Expected signature for ATmega328P is 1E 95 0F
         Double check chip, or use -F to override this check.

avrdude done.  Thank you.

I get a different error code when I don't apply pressure to the jumperwire / board connections.

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)

Error while burning bootloader.
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.

I think that I did everything right with the board selection etc.
But on the other hand there is somewhere a mistake and its most likely that I am the one to blame xD

I am using Arduino IDE version 1.8.12 (Windows Store 1.8.33.0) and Windows 10 if this makes any different.
I have attached a screenshot of the part of my PCB schematic with the custom Arduino

I tried to provide all information necessary, but if you need anything else just ask.

Can anybody please help me with my problem?

Arduino screenshot.JPG
Arduino screenshot.JPG701×504 73.8 KB

2

Where is the capacitor on RST?

3

aarg:
Where is the capacitor on RST?

What do you mean? The ATmega328 doesn't need a capacitor on reset, does it. As far as I know the cap is only needed if you have the USB to serial converter on the board. Am I wrong?

Or do you mean the capacitor on the Programmer Arduino? I tried it with and without a E-cap between reset and GND on the Mega

4

Check your jumper wires for continuity. Sometimes you will get jumper wires that have a broken or intermittent connection.

5

pert:
Check your jumper wires for continuity. Sometimes you will get jumper wires that have a broken or intermittent connection.

I just tried a new bunch of jumpers didn't change anything at first but then it somehow worked with the Ardunio Mega and uno.

So I tried it with new jumpers on my own PCB design and it's still not working there.

Which brings me back to the suspicion that there is something wrong with my design.

6

The random or all zeros signature can definitely be caused by a wiring issue. Here are some raw notes I made from when I was experimenting to try to find correlations between different possible wiring issues and the resulting error messages:

  • avrdude: Device signature = 0x000000
  • Target not powered.
  • MISO/MOSI/SCK/RST not connected
  • MOSI/SCK swapped with RST
  • MISO swapped with RST
  • RST-RST instead of 10-RST reset connection
  • ICSP cable backwards on header
  • `avrdude: Device signature = {some random wrong signature}
  • MOSI/SCK swapped with MISO
  • avrdude: Device signature = 0xffffff
  • MISO/RST swapped
7

Does your custom board have a crystal or resonator to set the ATmega clock? If not, and the chip is set to expect a crystal, the chip's clock is not running. Serial programming requires the chip clock to be running.

Adafruit has a version of the ArduinoISP sketch that provides an 8 MHz clock on Pin 9: GitHub - adafruit/ArduinoISP: A fork of the ArduinoISP that has 8mhz output clock Upload this version of ArduinoISP to your ISP Arduino. Connect Pin 9 of the ISP Arduino to the XTL1 pin of the ATmega168/328P. That will provide an 8 MHz clock to allow programming without a crystal.

8

johnwasser:
Does your custom board have a crystal or resonator to set the ATmega clock?

I am using a ceramic resonator (CSTCE16M0V53-RO Ceramic Crystal SMD 16MHZ) but I didn't implement any 22p caps from the resonator to GND (because my research at that time showed that they weren't necessary if you are using a resonator instead of a crystal. But I am not sure anymore).

johnwasser:
Adafruit has a version of the ArduinoISP sketch that provides an 8 MHz clock on Pin 9: GitHub - adafruit/ArduinoISP: A fork of the ArduinoISP that has 8mhz output clock Upload this version of ArduinoISP to your ISP Arduino. Connect Pin 9 of the ISP Arduino to the XTL1 pin of the ATmega168/328P. That will provide an 8 MHz clock to allow programming without a crystal.

I tried it but it didnt worked either but it wasn't so easy because I have the SMD version of the ATmega and I dont have a pad for Pin9. If you still think that this might work (regarding the new information I provided) I off course gonna try it again.

pert:
The random or all zeros signature can definitely be caused by a wiring issue. Here are some raw notes I made from when I was experimenting to try to find correlations between different possible wiring issues and the resulting error messages:

I am quite sure that I eliminated all wiring issues, I checked it again and again... (and measured the connection with a multimeter) but I gonna keep checking

I didn't some more testing:

  1. I managed to burn the bootloader from the Mega to the Uno in 9 out of 10 cases.
  2. I soldered an other custom board but this time only the ATmega with its complementary components, nothing else (same "custom Arduino" design as the other board) same results.
  3. I tested all pins for shorts to its neighbor pins but I couldn't find any.
  4. I used a separate power supply for the Arduino and got different error codes.
  5. I changed the jumper wires to to "normal wires"
  6. At one point during testing I got different error messages like each time I tried to burn the bootloader (avrdude: Device signature = 0x..........) the characters after the X changed.
  7. I eventually got the message that I burned the bootloader successfully (on the first board), but when I tried to upload the Blink sketch I received this message
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x03
  1. I tried to burn the bootloader again but since then I only get the following error code (on both boards) although I did everything as before
avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.

Do you think its gonna be easier if I use a ISP programmer (Usbasp Avr or similar) I don't have one yet but I would order one if you think it would work.

I start getting a little desperate!!

9

m4tthias98:
I eventually got the message that I burned the bootloader successfully (on the first board), but when I tried to upload the Blink sketch I received this message

avrdude: stk500_recv(): programmer is not responding

avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x03

Are you uploading via the "5PAD_BOOTLOADER_CONNECTOR" shown on your schematic? If so, what do you have connected to it?

10

pert:
Are you uploading via the "5PAD_BOOTLOADER_CONNECTOR" shown on your schematic? If so, what do you have connected to it?

Yeah exactly these are just 5 pads to connect wires to. Very similar to the connector of an Arduino Pro Mini.
I used the Arduino Uno to program my board the same way I programmed my Pro Minis successfully (I actually tested it and reprogrammed one of my minis successfully)

This shouldn't be a problem, right??

11

The reason I asked is because the ATmega328P must be reset at the right time during the upload. If it isn't reset, you get this error message (though there are a bunch of other possible causes too). On the Pro Mini, you connect the DTR or RTS pin of the USB to serial adapter to the "GRN" pin on the Pro Mini's "FTDI header". That "GRN" pin is connected to the ATmega328P's reset pin via a 0.1 uF capacitor. That generates the pulse that resets the board when the connection is opened to start the upload. Your board doesn't have this 0.1 uF capacitor.

When using the Uno as a USB to serial adapter, I suppose if you connect the Uno's reset pin to the reset pin on your custom board you'll be able to use the reset pulse generated from the Uno's auto-reset circuit? Is that how you have the Uno wired to your board.

How do you have the Uno's RX and TX pins connected?

12

There should be a 0.1uF cap between DTR on the FTDI connector, and the RESET pin. Since a typical FTDI doesn't have this, it has to be on the target board. That is the cap I referred to earlier.

13

aarg:
There should be a 0.1uF cap between DTR on the FTDI connector, and the RESET pin. Since a typical FTDI doesn't have this, it has to be on the target board. That is the cap I referred to earlier.

I don't use a FTDI, I use the Arduino Uno.
I am not using the DTR pin. I connect the reset pin manually to ground at the right time (same way I do it with the Pro mini successfully)

pert:
When using the Uno as a USB to serial adapter, I suppose if you connect the Uno's reset pin to the reset pin on your custom board you'll be able to use the reset pulse generated from the Uno's auto-reset circuit? Is that how you have the Uno wired to your board.

How do you have the Uno's RX and TX pins connected?

I connect the Reset pin of the Uno to GND (this way the MCU on the Uno gets [ignored]) and press the reset button on the Pro mini at the right time. The timing doesn't need to be that precise (at least with the Pro Mini and since they are using the same MCU it should be the same thing)

Uno > custom board / Pro Mini
RX > RX
TX > TX
5V > 5V
GND > GND

I know that you wire it RX > TX and vice versa. But that's how it worked on the Pro Mini. And I even tried both ways just to make sure. And yes I am planning to purchase an FTDI module, but I didn't had any problems using the Uno so far...

I think the problem is with the bootloader. But I might be wrong since I don't have that much experience.

Don't get me wrong please, I am really thankful for your suggestion.

14

m4tthias98:
I am not using the DTR pin. I connect the reset pin manually to ground at the right time (same way I do it with the Pro mini successfully)

OK, that works, as long as you reset at the right time. The trick is that when you click the Upload button in the Arduino IDE, it first compiles the sketch, then starts the upload. So if you reset the board when you click the Upload button, the bootloader will have already timed out by the time the upload starts. The time to do the reset is when you see the sketch size printed out in the IDE's console pane.

However, that actually isn't an issue on the first upload after burning the bootloader because until that first sketch is uploaded the bootloader runs constantly and so no reset at all is needed on the first upload.

m4tthias98:
at least with the Pro Mini and since they are using the same MCU it should be the same thing

The timing is dependent on how long the bootloader runs before timing out. If I remember correctly, the outdated "ATmegaBOOT" bootloader of the Pro Mini has a longer timeout duration than the modern optiboot bootloader used by the Uno and the default Nano board setting.

m4tthias98:
Uno > custom board / Pro Mini
RX > RX
TX > TX
5V > 5V
GND > GND

Looks good.

m4tthias98:
I know that you wire it RX > TX and vice versa.

This is an odd situation where making the connections RX-RX, TX-TX according to the markings on the Uno actually results in the correct RX-TX, TX-RX connections. The reason is because the RX and TX marked on the Uno's silkscreen is referring to the pins on the Uno's ATmega328P but you aren't communicating between the Uno's ATmega328P and your custom board. Instead, you are communicating with the USB to serial adapter chip on the Uno. That chip has an RX-TX, TX-RX connection to the Uno's ATmega328P.