Why would bootloader get lost

I now have two Duemilanove boards where the bootloader has stopped working. I was running a sketch that was periodically connecting to a remote web site via WiFi and reading down some data. The board first starting showing failures to connect to the remote sites and appeared to have halted or just hung up somewhere and no longer execturing the loop(). I first noticed this because I have an external LED that stopped blinking. I reloaded the sketch as part of tracking down why this might have started happening after several days of proper operations. The board continued to show the same failure and halting again. But after a few attempts at removing the power from the board and reinserting power and restarting the sketch, the board just stopped responding. The Green light is on but that’s it. When I try to reflash the board, AVRDUDE reports stk500_getsync(): not in sync: resp=0x00. This is becasue it is not seeing a response from the bootloader.

This will be the second Duemilanove board that in which I have to reflash the bootloader. Can any think of a reason why the bootloader should stop working? It is supposedly locked into memory in an area which should not be overwritten. Could the watchdog timer be accidently enabled and is hanging up the loader? Is the watchdog timer enable if the wrong memory location was written into? I would hope the process of turning on the watchdog would have a couple of steps that must be executed so that a rogue program can’t accidently turn it on.

Any thoughts on why a bootloader should stop working?

When the Duemilanove (and early Uno's) are automatically reset by jiggling the serial port's DTR line, a high voltage spike will often occur on the processor RESET pin. I understand that this can put the ATmega into high voltage programming mode and wipeout the bootloader. I've experienced this on several older Uno's.

Solution is addition of a signal diode between +5V and RESET (cathode to +5V).

At worst, this will fix a known issue. At best, it will also solve the problems you are having.

Jim

Are you using the watchdog timer in your sketch?

There is no evidence at this stage that the bootloader is lost.

I have a sketch here that detects the chip signature, and does an MD5 sum of the bootloader. That would confirm whether or not the bootloader has indeed disappeared.

http://gammon.com.au/forum/?id=11633

Also, do you have anything plugged into pins D0 and D1 at the time you are trying to upload the new sketch?

[quote author=Nick Gammon link=topic=112880.msg849376#msg849376 date=1341473454] Are you using the watchdog timer in your sketch?

There is no evidence at this stage that the bootloader is lost.

I have a sketch here that detects the chip signature, and does an MD5 sum of the bootloader. That would confirm whether or not the bootloader has indeed disappeared.

http://gammon.com.au/forum/?id=11633

Also - is anything plugged into D0 and D1? [/quote]

No the sketch has never used the watchdog timer. I am aware of the problems associated with enabling the watchdog and how it can cause the bootloader to hang if the bootload does not turn it off. I was just wondering if some program execution error could have triggered the watchdog to cause the problem.

Why do you indicate that there is no evidence that the bootloader is lost. The last time the same thing happened, reflashing the bootloader brought the board back to workng condition. I looked at the sketch you showed regarding checking the bootloader. It seems easier just to reflash the bootloader when I get the opportunity. I use a second Arduino board as the programming unit.

The sketch which was running when this occurred has been under test for a while. I run it for several days at a time with no failures. I have no evidence that the code is going off on a tangent and not returning to the loop() mainline. As long as it is running the loop mainline the LED would keep blinking. I was in the processing of trying to narrow down where in the sketch the loop() would stop working when I found I was unable to download a code update with some debugging code in place to determine where things went south. At that point I was unable to download the new sketch since the bootloader would not respond.

JimG: When the Duemilanove (and early Uno's) are automatically reset by jiggling the serial port's DTR line, a high voltage spike will often occur on the processor RESET pin. I understand that this can put the ATmega into high voltage programming mode and wipeout the bootloader. I've experienced this on several older Uno's.

Solution is addition of a signal diode between +5V and RESET (cathode to +5V).

At worst, this will fix a known issue. At best, it will also solve the problems you are having.

Jim

Is thre a specific diode that I should place between the 5v and RESET line to prevent this? Could one just use an LED as the diode which would also show that power was present?

jmosk: Why do you indicate that there is no evidence that the bootloader is lost. The last time the same thing happened, reflashing the bootloader brought the board back to workng condition.

The evidence would be, if you ran the sketch I suggested, and it showed the bootloader MD5 sum was wrong (compared to what you expect).

Or you read the bootloader to disk, and compare the hex files, and find they differ.

Reflashing the bootloader also erases the current program, so, if there is a problem with the code (eg. the watchdog timer) then erasing the problem code fixes that. The bootloader should be impossible for the sketch to self-erase, if the fuses are set correctly.

Next time, try holding down the reset button before you power on the board, then (with it held down) plug in the USB and upload the sketch. Once it starts to say "uploading" release the reset button (you may need someone to help you, or connect a wire from the reset pin to the Gnd pin, and yank it out at the appropriate point).

jmosk: Is thre a specific diode that I should place between the 5v and RESET line to prevent this? Could one just use an LED as the diode which would also show that power was present?

I have used 1N4148 because I have a bunch of them. I think others have used 1N914. It should be a small signal diode because a fast response time is needed. An LED won't work.

Here's a link to the thread where the problem was clearly identified: http://arduino.cc/forum/index.php/topic,64256.0.html

Jim

JimG:

jmosk: Is thre a specific diode that I should place between the 5v and RESET line to prevent this? Could one just use an LED as the diode which would also show that power was present?

I have used 1N4148 because I have a bunch of them. I think others have used 1N914. It should be a small signal diode because a fast response time is needed. An LED won't work.

Here's a link to the thread where the problem was clearly identified: http://arduino.cc/forum/index.php/topic,64256.0.html

Jim

An LED may work and it wouldn't hurt to try. I suggest getting the proper diode though.

The reasons I recommended against an LED were

  1. Because it would be reverse biased (except for very fast pulses immediately after the DTR toggles) and will not illuminate the way jmosk wanted/expected;

  2. The forward voltage is higher than 1N4148 so it won't clamp as close to 5V;

  3. I was unsure of the response time.

But....you may very well be right, and it might work just fine if installed with the correct polarity. And it would be kinda cool if you could actually see a quick flash each time it operated as a clamp.

Jim