Bootloader Overwritten by Regular Sketch Upload

I have an integrated Arduino “circuit” on a custom designed PCB. I am able to flash the ATmega328P with the bootloader without any problem. When I upload the example “blink” sketch to the board, it always works the first time. If I try again, I don’t get a response from the board. I found that the bootloader is gone every time. If I reflash the bootloader, a sketch loads fine, the first time. I can repeat the problem every time. Obviously the bootloader is being overwritten or possibly corrupted by the sketch load.

Just a little more info. I based this on a 5V/16 MHz Pro Mini schematic, so I used that for my bootloader and target “board”. I noticed that there is not an option for the “328P”, just the “328”. Could this be the issue?

Thanks!

-Jason

How are you installing the bootloader?

[quote author=Coding Badly link=msg=2766045 date=1463861352] How are you installing the bootloader?[/quote]

I'm using the Arduino IDE with my AVRISP MKII

-Jason

Tools / Burn Bootloader?

[quote author=Coding Badly link=msg=2766367 date=1463886901] Tools / Burn Bootloader?[/quote]

Yes. I'm making sure to have the proper board selected, since that seemed to determine which version of the bootloader is flashed to the board. In my case I'm using the Arduino Pro/Pro Mini.

Just to clarify, I am burning the bootloader to an ATmega328P running on +5V at 16 MHz. Noticed that when I select the Pro Mini, I only have the choices of ATmega128 or ATmega328. There is not an ATmega328P option. However, I do not get any errors when flashing the bootloader. I can also upload a single sketch to the chip after flashing the bootloader. It's only subsequent attempts to upload a sketch that fail. If I reflash the bootloader, then I can upload a sketch again, but only the one time.

KE4NYV: I'm using the Arduino IDE with my AVRISP MKII

-Jason

Are you also uploading the sketch with the AVRISP MKII ?

If so, that's why the bootloader is being overwritten. I guess that begs the question "why do you need a bootloader at all". Apart from the initial setting of the fuses, the bootloader isn't required if you upload sketches via ISP.

Ian.

ian332isport: Are you also uploading the sketch with the AVRISP MKII ?

If so, that's why the bootloader is being overwritten. I guess that begs the question "why do you need a bootloader at all". Apart from the initial setting of the fuses, the bootloader isn't required if you upload sketches via ISP.

No, I should have specified when loading a sketch, I'm doing that the normal way through the IDE. Verify/Upload through the serial pins using an FTDI cable. It always works the first time, then subsequent tries fail.

Nowhere have you actually confirmed that your are selecting “Tools\Burn Bootloader”

You mentioned uploading the sketch but never said you were selectng "Burn Bootloader’.

Are you ?

Maybe an issue with the DTR of the FTDI to the RST of the Arduino (capacitor ?) or how the DTR is handled in software.

KE4NYV: I have an integrated Arduino "circuit" on a custom designed PCB.

Verify/Upload through the serial pins using an FTDI cable.

Did you include a diode on RESET to suppress spikes?

justone: Maybe an issue with the DTR of the FTDI to the RST of the Arduino (capacitor ?) or how the DTR is handled in software.

And that is indeed the case.

This is a perfectly well-known problem.

If you burn the bootloader to the board - necessarily using an ISP - the sketch area is completely erased. This means that when the bootloader times out and defaults to running the sketch - there is no sketch, so it (almost instantly in effect) runs through the memory and restarts the bootloader at the top of memory. It continues to repeat this until you actually tell the IDE to perform a sketch upload in which case the bootloader intercepts it and loads the sketch. And runs it.

Now the sketch runs. If you attempt to perform an upload, the IDE cycles the DTR line but because it is not (effectively) connected to the Reset on the chip, the bootloader is not restarted when the upload is attempted and while the first sketch upload was successful, none after are as the bootloader is not being started.

Of course if you hit the Reset button manually the moment "Done Compiling" appears in the blue status bar on the IDE, you can upload a new sketch. But it is easier if you have the capacitor from DTR on the adapter to Reset on the Arduino.

Note - do not put a capacitor from Reset to ground.

Paul__B: And that is indeed the case.

This is a perfectly well-known problem.

If you burn the bootloader to the board - necessarily using an ISP - the sketch area is completely erased. This means that when the bootloader times out and defaults to running the sketch - there is no sketch, so it (almost instantly in effect) runs through the memory and restarts the bootloader at the top of memory. It continues to repeat this until you actually tell the IDE to perform a sketch upload in which case the bootloader intercepts it and loads the sketch. And runs it.

Now the sketch runs. If you attempt to perform an upload, the IDE cycles the DTR line but because it is not (effectively) connected to the Reset on the chip, the bootloader is not restarted when the upload is attempted and while the first sketch upload was successful, none after are as the bootloader is not being started.

Of course if you hit the Reset button manually the moment "Done Compiling" appears in the blue status bar on the IDE, you can upload a new sketch. But it is easier if you have the capacitor from DTR on the adapter to Reset on the Arduino.

Note - do not put a capacitor from Reset to ground.

Paul, thank you for that answer and actually explaining it! That sounds exactly like what is happening. I have already made some changes to my schematic/board and when I get home I'm going to see if I can add these parts onto the first revision board to get it working and prove this is the problem.

-Jason

I know this is a very old thread but it is the best answer to the upload problem due to the reset circuit.
I have followed Paul__B 's advice and I am perplexed: It works sometimes.

Specifically:
Built a board using Atmega328PB

Bootloader burned via ISP using AVRISP mkii. Works great. Using MiniCore so I can select my exact chip Atmega328 variant PB

Upload via FIDI.

Problem: Works first time and multiple times afterwards. Sometimes. Then it may not upload, getting the usual sync error. Then it works.

Works intermittently, like my schematic is close buy not quite right.

If I press reset button it does load every time.

My schematic is attached. Is there something I have wrong? Wrong value on a cap, wrong diode?



Left Side of Schematic attached
[

](https://forum.arduino.cc/index.php?action=dlattach;topic=402110.0;attach=332281;image)

RichKC24: My schematic is attached. Is there something I have wrong? Wrong value on a cap, wrong diode?

I would be wondering what that mysterious wiring is to the reset pin that has been cut off the left hand side of your schematic?

Paul__B - It is going to VCC. I added the left side of schematic in original post.

Can't see a problem here - so it works with the pushbutton but not with the FTDI.

I suspect the FTDI! :astonished:

Do "SIGNAL" and "VCC2" connect to anything?

AVCC should not connet to VCC directly. Only have a 0.1uF to Gnd.

Schematic looks fine otherwise. Try bootloading the part as an Uno vs a Promini. Later code, less space used, same functionality. I bootload all my 328P devices as an Uno. Less confusion over what is to select as the board type too.

In boards.txt, change this line in the Uno section

uno.build.variant=standard

to

uno.build.variant=eightanaloginputs

as you using analog input 6, which an Uno does not have. (not available in the 28 pin DIP, but is brought out in the 32 TQFP).

Paul__B: Yes works every time wiht the reset button. Thanks for reviewing the reset circuit. Good to know it is right, I have been wondering. I will try another FTDI, also wonder if my computer's USB port is getting flaky/worn contacts.

CrossRoads:

Reset Button pins Signal and VCC2 do not connect to anything. Since they are connected internally to GND and VCC I thought it would not matter.

AVCC on Atmega328 - "Connect to ground through 0.1uF to Ground" like this?

Regarding using a chip with Analog input 6, I have MiniCore installed on the Arduino IDE so I have not selected Board Uno but it set to: Board - ATmega328 Variant - 328PB. Will this solve the problem regarding changing to "uno.build.variant=eightanaloginputs" ?