can't upload sketch - led13 blinking rapidly

Forum 2005-2010 (read only) Hardware Troubleshooting
#1

I got a freeduino serial 2.0 board a few days ago from nkcelectronics. I’ve been using it all weekend, and it worked fine until today, when I tried to upload a sketch, and it failed with the typical “not in sync” error. When I power on the arduino, the D13 LED blinks one time, pauses briefly, then starts blinking rapidly. This is particularly bizarre, because the sketch I uploaded does not read or write to any of the outputs.

Any ideas as to what is going on? Tomorrow I will try to make a parallel programmer out of a spare scsi cable…

#2

"It worked fine until today"... did you ever have a successful upload?

Which LED blinks rapidly? The D13 or the power?

If you buy a board and the D13 LED blinks before you ever put a sketch on it, don't be surprised if the vendor put a test program on there first.

#3

It worked fine before today, as in I've been uploading sketches to it all weekend, got an LCD to work with it, etc.

The D13 led is the one blinking. And the last sketch I uploaded does not blink the led, or control any of the I/O (just the serial port), so it has no excuse to blink! :)

#4

Well, I built a parallel programmer and burned a new bootloader. I am now able to upload sketches.

It's sort of unsettling that it was this easy to trash the bootloader. I think I'll experiment with uploading sketches via the commandline, rather than the IDE.

#5

If you can figure out HOW you manager to hurt the bootloader, that would be really helpful. The rapidly flashing LED is particularly mysterious. I suppose that one explanation could be that you managed to turn on the watchdog, and what you're seeing is the bootloader's initial flash, occuring ever fraction of a second as the watchdog resets the CPU...

#6

I think at that point I was writing a float_to_string function that returned a pointer. My best guess is that I accidentally wrote to a memory space that I wasn't supposed to.

If it happens again I'll post the code that potentially caused the problem.

#7

Well, I can pretty exactly duplicate the behavior you said you saw by putting the following snippet in my sketch’s setup function:

  // Evil code to turn on the watchdog at an interval smaller than the
  // bootloader waits for characters; leads to a nasty reset loop.
     WDTCSR |= (1<<WDCE)+(1<<WDE);
     WDTCSR = (1<<WDE) | 0x100;

This turns on the watchdog that resets the cpu ever 0.25s; long enough for the bootloader to start and blink the led but not long enough to do anything useful. And the watchdog setting survives reset, so neither auto-reset nor button help…
However, on my SB Freeduino at least, the power-on behavior is something differet, and takes several seconds before leaving the bootloader and starting the sketch that munges the watchdog times, so I CAN load a new sketch by hitting the ide upload button and then immediately turning the arduino ON. (Your bootloader may vary.)
The relevant watchdog control register appears at memory location 0x60, BTW. It wouldn’t be hard to overwrite it (although you have to overright it twice, close together, to actually change the paramaters, according to the manual…)
(here’s the whole sketch I used to “break” my arudino.)

/*
 * Blink
 *
 * The basic Arduino example.
     :
 * http://www.arduino.cc/en/Tutorial/Blink
 */

int ledPin = 13;                // LED connected to digital pin 13

void setup()                    // run once, when the sketch starts
{
  pinMode(ledPin, OUTPUT);      // sets the digital pin as output
  
  // Evil code to turn on the watchdog at an interval smaller than the
  // bootloader waits for characters; leads to a nasty reset loop.
     WDTCSR |= (1<<WDCE)+(1<<WDE);
     WDTCSR = (1<<WDE) | 0x100;
}

void loop()                     // run over and over again
{
  digitalWrite(ledPin, HIGH);   // sets the LED on
  delay(1000);                  // waits for a second
  digitalWrite(ledPin, LOW);    // sets the LED off
  delay(1000);                  // waits for a second
}
#8

I don't know how I would have managed to do that, but it's interesting to see the result duplicated.

I certainly tried various timings with the reset and upload buttons, but had no luck, but like you said, maybe that's the bootloader. I don't know which one came on it... I'd assume the standard decimilia one.

#9

Hmmmm, sounds like exactly the same thing happened to me today. The description of the symptoms is 100% accurate My "guestimation" is that somewhere my program tried to write data to an array at an index that was bigger then the array was defined.

Indeed disturbing that the bootloader could get trashed this easily due to software errors.

Ok, now I need to find a way to burn a new bootloader ...

#10

Build a parallel programmer. It was easy.

#11

Indeed disturbing that the bootloader could get trashed this easily due to software errors.

To me that`s why the lock bits , to stop anything changing the bootloader.

#12

I my example "reproduction" of the problem, I didn't actually damage the bootloader; I just enabled the watchdog in a manner that failed to give the bootloader a chance to run...

Perhaps the bootloader should clear the watchdog...

#13

Well I seem to be in this same boat in terms of having a borked bootloader. When I plug my Arduino Duemilanove board in via USB the LED 13 starts blinking like mad. Resetting the board only stops the blinking while my finger is holding in the button. As soon as my finger lets go of the reset button, it starts blinking like mad again.

The sketches I've been uploading are really, really simple, so I have no idea how I did this to my board.

I'm totally new to this field, so I guess I'm off to go learn how to build a parallel programmer so I can burn a new bootloader.

1 Like
#14

I followed these instructions:

http://arduino.cc/en/Hacking/ParallelProgrammer?from=Main.ParallelProgrammer

I have windows xp, and did not need to install the drivers mentioned at the end.

#15

Well, I guess I'm not in the same boat. I seem to be in a worse boat... and it's sinking.

I built a parallel programmer by following these instructions. When I connect it up to the 3x2 pins on the Arduino board (even with no external power), LED13 lights very, very dimly. Connecting up the board to external power, LED13 glows a bit brighter, but still dim. When I try to burn the bootloader from the Arduino IDE, despite having the right board selected in the menus, it says I have the wrong microcontroller board plugged in. Here's the error message:

avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATMEGA168 is 1E 94 06
avrdude: AVR device not responding
 ***failed;
avrdude: verification error, first mismatch at byte 0x0000
         0x00 != 0x07
avrdude: verification error; content mismatch

Some more data...

With the parallel programmer plugged into the Arduino board, when I plug the external power in, I see this sequence:

TX,RX - FLASH ONCE pause TX, RX - FLASH AGAIN pause LED13 - TURNS ON AND STAYS LIT DIMLY

But if I plug in the external power, without the parallel programmer plugged in, I see this sequence:

TX,RX,LED13 - FLASH ONCE pause TX,RX - FLASH AGAIN pause LED13 - STARTS FLASHING LIKE MAD CONTINUOUSLY

Does anyone have any clue what's going on here? Am I just out a chip and need to buck up and pay for a new one? Seems like there's got to be some way to get it working again, but I'm all out of ideas (partly because I'm new to this). I'm also reluctant to just buy a new chip because I still don't know what caused this one to go bad, and the last thing I want is to get a new one and just have it mess up too.

#16

Whew... it works again now. Hans from DorkbotPDX was kind enough to bring his USBTinyISP programmer and burned a new bootloader onto my chip for me. It works great now and it burned the bootloader without a hitch.

#17

Reply #4 - If you can figure out HOW you manager to hurt the bootloader, that would be really helpful. ... Reply #5 - I think at that point I was writing a float_to_string function that returned a pointer. My best guess is that I accidentally wrote to a memory space that I wasn't supposed to.

I've just spent the past day or so trying to get a similar problem sorted (eaxctly the same avrdude messages etc). Two possibilities that come to mind as regards the above:

1) I created a sketch that overwhelmed the RAM space with lots of diagnostic messages (I didn't realise that all so-called "constant" strings are actually treated as initialised data by GCC - see http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1236113624/0#0). Maybe by doing so I somehow managed to access I/O space instead of RAM..?

2) to get round this, I started using the "PROGMEM" constuct (see http://www.arduino.cc/en/Reference/PROGMEM and http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html)...lots of pointers and type conversions here. :-/

#18

I am experience the same problem where the LED is blinking crazily fast!!!

My "guestimation" is that somewhere my program tried to write data to an array at an index that was bigger then the array was defined.

Why would writing an array at an index bigger than defined cause problems? Shouldn't the program just complain of index out of bound? I want to know because I was playing around with a double array when I "killed" the bootloader.

#19

I created a sketch that overwhelmed the RAM space with lots of diagnostic messages

I appear to have trashed autoreset on my Nano by using too much memory. I can still upload sketches but have to manually hit reset just before avrdude is called, otherwise it doesn't work.

Shouldn't the program just complain of index out of bound?

Ha! C isn't quite like that. Imagine someone giving you a loaded gun, politely suggesting you don't shoot yourself but then happily watching as you proceed to blow your foot off. That's memory management in C...

Andrew

#20

so is there anyway to prevent these problems: overwhelming RAM or out of bound array writing (other than relying on my programming skills)?

I managed to burn the bootloader using the method found on this page, but I am afraid I am going to screw up the boot loader again
http://www.geocities.jp/arduino_diecimila/bootloader/index_en.html