Arduino Bootloader Corrupted

What are the known things that can cause a bootloader to corrupt? Of late there have been a few cases of bootloader corruption and i'm wondering what leads to this. There are times when the led on the 13th pin is constantly high even though it is not used in the program at all. Also what happens say when in the middle of serial communication a arduino resets owing to power starvation?

Hmm, the wear and tear of the flash memory?

A sledgehammer???

Don

What are the known things that can cause a bootloader to corrupt?

I've posted this question in the past and got no response. So many have posted here of bricked Arduinos that were saved by reloading the bootloader only. It it's true then someone should be able to perform corrupting the bootloader on purpose. So can any software guru here produce code that causes the bootloader to go bye bye on purpose?

Lefty

My understanding from the datasheet... When the voltage level is too low, the processor will continue to run but may not correctly execute instructions. For example, instead of performing a register-to-register move it may execute a call. There is some hint that write-to-flash instructions can be executed instead of the intended instruction.

But, the brown-out-detector is supposed to prevent this problem from occurring. It's purpose is to hold the processor in reset through a low voltage situation.

So, the first question is, "How is the BOD configured?" (the configuration is done through fuses)

I remember seeing a sketch around here that was proven to kill the bootloader.

It may of had to do with writing large arrays to PROGMEM as discussed here.

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1248470794

The AVR chip has some "memory protection" bits that would prevent the non-bootloader code from writing the bootloader space, but the arduino environment does not seem to set these, so that means that an inappropriate instruction in the sketch could overwrite parts of the bootloader... -Ulock:w:0x3F:m

But that's probably not what is happening, since most sketches will not contain the rather specific instruction sequence necessary to write flash. It's more likely that something like a buffer overflow causes the user sketch to "jump" to the middle of the bootloader code, just where it is about to do something like, oh, erase a page... The memory protection bits could still fix this...

hmm. Both of the Arduinos I have on my desk (a real Uno with m328, and an SB Freeduino with m168) claim to have "protected" the bootloader memory, but that's not what the "burn bootloader" command will do!

Here's a sketch to dump such things...

#include <Flash.h>
#include <avr/boot.h>
/*
 * SIGRD is a "must be zero" bit on most Arduino CPUs; can we read the sig or not?
 */
#define SIGRD 5

void setup()
{
  Serial.begin(9600);
}

byte fuse_bits_low;
byte fuse_bits_extended;
byte fuse_bits_high;
byte lock_bits;
byte sig1, sig2, sig3;
byte oscal;

void space() {Serial.print(' ');}

void loop()
{
  delay(2000);

  cli();
  fuse_bits_low = boot_lock_fuse_bits_get(GET_LOW_FUSE_BITS);
  fuse_bits_extended = boot_lock_fuse_bits_get(GET_EXTENDED_FUSE_BITS);
  fuse_bits_high = boot_lock_fuse_bits_get(GET_HIGH_FUSE_BITS);
  lock_bits = boot_lock_fuse_bits_get(GET_LOCK_BITS);
  sig1 = boot_signature_byte_get(0);
  sig2 = boot_signature_byte_get(2);
  sig3 = boot_signature_byte_get(4);
  oscal = boot_signature_byte_get(1);
  sei();
  
  Serial << F("\nFuse bits (L/E/H): ");
  Serial.print(fuse_bits_low, HEX);
  space();
  Serial.print(fuse_bits_extended, HEX);
  space();
  Serial.print(fuse_bits_high, HEX);
  Serial << F("\nLock bits:         ");
  Serial.print(lock_bits, HEX);
  Serial << F("\nSignature:         ");
  Serial.print(sig1, HEX);
  space();
  Serial.print(sig2, HEX);
  space();
  Serial.print(sig3, HEX);
  Serial << F("\nOscal:             ");
  Serial.println(oscal, HEX);
  Serial.println();

  while (1) {
    if (Serial.read() > 0)
      break;
  }
}

Ah. My mistake? It looks like the "burn bootloader" command will unlock the boot area memory protection, burn the new bootloader, and then re-lock the memory protection. I didn't notice since I wasn't really burning a bootloader!

That should mean that the bootloader is incorruptible...
(but I've corrupted mine at least once!)

That should mean that the bootloader is incorruptible...
(but I've corrupted mine at least once!)

So the mystery still lingers. :wink:

Well...

  1. You can appear to corrupt your bootloader by enabling the watchdog timer. It doesn't actually break, but the watchdog keeps expiring and resetting the chip before a new sketch can be uploaded. This depends on the bootloader (adaboot and optiboot all "correctly" disable the watchdog in the bootloader, for example), and you can usually fix the problem by power-cycling the avr instead of just resetting it. (also depending on bootloader. And it's gotten more difficult to power-cycle the AVR independently on new Arduinos; this works better with the "bare bones" boards with a separate USB cable.)

  2. There are reports that a sketch that sends larges amounts of data to the serial port will prevent the next sketch from downloading.

  3. Even if the bootloader memory is correctly protected, it's possible to reprogram the fuse bytes in a way that would prevent it from executing properly. It would also presumably be possible (but very unlikely) to reprogram the memory protection byte and THEN corrupt the bootstrap memory.

If anyone has a bricked chip that they're willing to mail me, I'm willing to apply some effort to trying to figure out what is wrong with them. In theory, I have the tools (a "real" STK500.)

Talking of fuse lock bits... i'm not sure if they work.... I've used avr bit bang for programming and i can easily reflash a new bootloader without writing the unlock bits... it doesn't even throw an error message.

My understanding from the datasheet... When the voltage level is too low, the processor will continue to run but may not correctly execute instructions.

This could be the cause... as most corrupted bootloaders had something to do with motors being run and data printed to the serial port at the same time. In addition, the front usb ports on pcs are not producing enough current as the back ones do. perhaps this could be another reason. my pickit2 programmer doesnt work on the front usb sockets but works fine with the ones at the rear.

I've used avr bit bang for programming and i can easily reflash a new bootloader without writing the unlock bits.

I didn't get the impression that the bootloader lock bits were supposed to have any effect on ISP programming, and I wouldn't expect arduino to use the ISP lock bits. And reprogramming the bootloader probably starts with a bulk chip erase that makes it academic anyway.

For corrupting the bootloader, we're only concerned with "software self-programming."