Go Down

Topic: can't upload sketch - led13 blinking rapidly (Read 7512 times) previous topic - next topic


Feb 11, 2009, 08:49 am Last Edit: Feb 11, 2009, 10:13 pm by JustinHoMi Reason: 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....


"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.


Feb 11, 2009, 06:42 pm Last Edit: Feb 11, 2009, 06:49 pm by JustinHoMi Reason: 1
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! :)


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.


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...


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.


Well, I can pretty exactly duplicate the behavior you said you saw by putting the following snippet in my sketch's setup function:
Code: [Select]
 // 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.)
Code: [Select]
* 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


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.


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 ...


Build a parallel programmer. It was easy.


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.


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...

Dylan Bennett

Feb 27, 2009, 08:19 pm Last Edit: Feb 27, 2009, 11:22 pm by MBoffin Reason: 1
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.


I followed these instructions:


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

Dylan Bennett

Mar 01, 2009, 04:57 am Last Edit: Mar 01, 2009, 04:58 am by MBoffin Reason: 1
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:

Code: [Select]
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
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:


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


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.

Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131