Simple blinking program seems to be interrupted ?

Hello I'am quite new to this Arduino world. So I just got my A.uno R3 up and running and I am trying a small program found here : http://arduino.cc/en/Tutorial/Array I reduced the delay variable to 50 ms to increase the speed and added af few delay lines to reduce the dutycycle of the leds. However after each 42 cycles, all leds are turned off for a few seconds and the onboard led no.13 does some flashing. After this it resumes correct program execution for another 42 cycles - and so on. This happens when powering through the computer usb as well as powering with a usb charger, so I guess it is not computer communication that interrupts the Arduino. Also tx and rx leds are off at all times, not indicating any communication.

What is happening ? Is it bad programming ? Is there some buffer in the Arduino that needs to be reset ? I would assume and hope that what ever program the Arduino is executing it should be able to go on for ever or at least more than 42 cycles before showing errors.

Thank you very much for your help and for an incredible forum in general. Best Regards. Jacob

Please post your code. We do not know exactly what changes you have made without seeing it.

Sorry.
Here is the complete code :

/*
  For Loop Iteration
 
 Demonstrates the use of a for() loop. 
 Lights multiple LEDs in sequence, then in reverse.
 
 The circuit:
 * LEDs from pins 2 through 7 to ground
 
 created 2006
 by David A. Mellis
 modified 30 Aug 2011
 by Tom Igoe 

*/

int timer = 50;           // The higher the number, the slower the timing.

void setup() {
  // use a for loop to initialize each pin as an output:
  for (int thisPin = 2; thisPin < 8; thisPin++)  {
    pinMode(thisPin, OUTPUT);      
  }
}

void loop() {
  // loop from the lowest pin to the highest:
  for (int thisPin = 2; thisPin < 8; thisPin++) { 
    // turn the pin on:
    digitalWrite(thisPin, HIGH);   
    delay(timer/5);                  
    // turn the pin off:
    digitalWrite(thisPin, LOW);
    delay(timer);    
  }

  // loop from the highest pin to the lowest:
  for (int thisPin = 7; thisPin >= 2; thisPin--) { 
    // turn the pin on:
    digitalWrite(thisPin, HIGH);
    delay(timer/5);
    // turn the pin off:
    digitalWrite(thisPin, LOW);
    delay(timer);
  }
}

OK, you posted it, but can you please edit the post and put the code in code tags. Select the code then click the # symbol above the smileys.

Please read the sticky posts at the strat of thsi forum for advice on how to use it.

How are the LEDs wired ? What value of current reducing resistors are you using ?

OMG! You’ve found the Ultimate question to life, universe and everything!

Except that Deep Thought did not reset itself once it had found the answer unlike what this Arduino appears to be doing.

Some compilers might object to the multiple definition of the same variable name "thispin" in loop().

Each declaration of the variable is in a for loop. Does that not make the variable local to the loop ?

Except that Deep Thought did not reset itself once it had found the answer

Maybe DeepThought’s millis rollover was greater than the 7.5 million years it took to compute The Answer.

No no, this is the question, not the answer!

I found this on the Deep Thought support forum :)

I have this in my program

delay(7,500,000 * 365 * 24 * 60 * 60 * 1000)

It seems very slow to respond to keypresses. Can anyone help ?

Some compilers might object to the multiple definition of the same variable name “thispin” in loop().

They’d be rubbish compilers then.

delay(7,500,000UL * 365 * 24 * 60 * 60 * 1000)

Sheesh, some people.

Yea yea... very funny :P. If I am going to make a parachute deployment for my rocket or something like that, I would welcome some more reliability than this. 7.5 milion years to rollover that's fine. Even a month would do. 42 cycles not good.

I use 220 ohm resistors like the author does. I didn't however plug in led number 2 (output 3) as I ran out of led's. But if such a misdemeanor can cause problems like this, Im not sure this is the way for me to go.

Just because something becomes computer controlled shouldn't mean that we should all bow and accept the necessity of an occasional restart. This is already the case with my computer end even my smart( :relaxed:) tv. I dread the day it becomes true for my car. And if I can help it, it is NOT going to happen for my homemade electronics.

Thank you AWOL. I will look into that. And thank you for your replies in general. You respond very fast.

OK, joking apart, I can't see anything obviously wrong with the code, and I wouldn't expect it to reset. Try changing the delay to something slower, and add some serial prints to the place where you light and extinguish the LEDs. Then disconnect the LEDs. If this all works, reconnect the LEDs, checking the wiring and double-checking the resistor values.

jensjacob: Just because something becomes computer controlled shouldn't mean that we should all bow and accept the necessity of an occasional restart.

Looks like it is restarting. They don't do that for nothing. I have one running for months.

It will be a wiring issue. Although ... where did you buy it?

I think you are right that it is restarting. When I push the reset button, all leds turn off and the onboard no. 13 led flashes in the exact same manner. I got it as a gift and it was bought on the internet though from a store still within the country.

Ok, I just spoke to a friendly person where the board was bought. Some simple software tests led him to believe that there might be errors on the board. Anyway, he will send a new board and have my board returned.

We wrote a simple program that would write to the serial monitor twice per second. It went on for longer than the blinking program without resetting itself so no problem there. Then output 13 (onboard led) was high for no apparent reason. We forced it low in the test program and that worked. But when declared as an input it went back to high (light) and that led him to believe that something might be wrong.

Actually that is quite common on the R3 because the onboard LED is driven by an op-amp (lmv358) to reduce the load on the pin. However if the pin is floating (input) the op-amp may turn on and light the LED. Mine does that, for example. As do others.

See: http://arduino.cc/forum/index.php/topic,136476.msg1093719.html#msg1093719