Mega 2560 - Led 13 often on without code

Hi,

Could you tell me why this simple code put onboard Led 13 always on ?

/* * * Controle d'un relai après un certain temps * */

int pinRelai = 31; // commande du relai (via transistor P2N2222AG)

void setup() { pinMode( pinRelai, OUTPUT ); }

void loop() { delay(5000); digitalWrite( pinRelai, HIGH ); delay(5000); digitalWrite( pinRelai, LOW );

}

What size resistor do you have connecting the digital output pin to the base of the transistor?

-br

10k ohm

I'm stumped. An interesting mystery. The relay is happy, right?

-br

Yes relay does function.

With some code, Led is on, with other it's off

Strange

Thierry

With some code, Led is on, with other it's off

Strange

Not really. Whether the pin is INPUT or OUTPUT matters. Whether the pin is HIGH or LOW matters. Without seeing the two different codes, all we can do is assume that it is perfectly normal.

I have a Uno and find that with sketches which don't even refer to that pin at all, the built-in led on 13 is on more often than not.

I stick these lines in at the top of each sketch, because having that led on when I don't want it on, annoys the cr@p out of me!

  pinMode(13, OUTPUT);
  digitalWrite(13, LOW);

Sounds like a bootloader bug. Worth reporting if it’s an official Arduino board.

-br

--> PaulS

You have an example of code in my post. I juste do copy-paste as a new program, run it and Led will light

--> JimboZA

Nice to meet another one with same problem :-)

Thierry

hi all,

i just received my arduino mega 2560 r3 and led on pin 13 is always on, even with "bare minimum" sketch. when i use the blink example it blinks correctly.

have you found any solution to this? is that the only problem you have or might this be just the tip of the iceberg and the whole board is flawed?

cheers, stefan

I drug out a selection of Arduinos - a Duemilanove, a Micro, a Mega, a Leonardo, a Due, and an Esplora. I loaded the same sketch onto each one. On the Due, the LED on pin 13 stayed on. On all the others, the LED on pin 13 was off while the sketch was running. Changing the pin from 31 to 13, for each board, caused the onboard LED to flash, as expected.

I guess, then, that JimboZA's suggestion is what you need to do, if having the onboard LED on bothers you.

hi Paul,

whoaa, thanks for your investigation! so pin13 is off on your MEGA but on on the DUE... seems random to me ;)

a resistor from pin 13 to ground "solves" the problem, i just hope that there aren't any underlying defects that cause this behavior.

thanks again, stefan

a resistor from pin 13 to ground "solves" the problem

That is what JimboZA's code does, in effect, but all in software.

Could a floating pin somehow drive the LED?

I just posted and then erased a post saying it's impossible to have what people are seeing with pin 13. But then I got thinking that unlike older arduino boards the current rev3 boards (uno and mega for sure) use an opamp to drive the led, and if the bootloader puts pin 13 back to input mode before jumping to the users sketch (is that the case), then the opamp will be seeing a 'floating input condition', so maybe it's possible for the newer boards to have a 'interrmittent' pin 13 indication? Never occured to me as I don't own any Rev3 boards. Not sure how a LMV358 opamp might respond to a 'floating input pin' condition.

What do others think?

http://arduino.cc/en/uploads/Main/Arduino_Uno_Rev3-schematic.pdf Lefty

hey retrolefty,

a really clever guy (uwefed) over at the german forum proposed more or less the same "opamp @ rev3 board theory".

so, do all rev3 boards do it and is it a normal behaviour? ;)

stefan

I think this one has been around before. The bootloader flashes the LED and it is probably chance that it is HIGH (although maybe INPUT) when it finishes.

[quote author=Nick Gammon link=topic=136476.msg1093825#msg1093825 date=1359442461] I think this one has been around before. The bootloader flashes the LED and it is probably chance that it is HIGH (although maybe INPUT) when it finishes. [/quote]

As I said I don't own a Rev3 Uno, but I am running optiboot in an older duem.. board. So I did the following:

  1. Loaded and ran the bare minimum example sketch and when run pin 13 led is off. Removed power and then repowered on with battery, led 13 still off.

  2. Added the below to bare minimum example which should just enable the internal pull-up for pin 13 if the pin if in input mode, other wise if the pin is left in output mode the output will be 'full on'. When it was run one can see the led on but very very dim.

void setup() {
  // put your setup code here, to run once:
digitalWrite(13, HIGH);  //enable pin 13 pull_up
}

void loop() {
  // put your main code here, to run repeatedly: 
  
}

So my conclusion is that optiboot leaves the bootloader and jumps to the application code with pin 13 in input mode and the internal pull-up turned off. So I think that leaves optiboot innocent of any random behaviour of pin13 led being on or off when starting a sketch symptom, if should always be off. So I think it's the newer hardware design using an op-amp section to drive the led that is responsible for any randomly on or off led when the users sketch starts, if that is indeed the true symptom being seen, as the result of the op-amp 'seeing' a floating input pin condition. I suspect even adding a 1 megohm pull-down external resistor to pin 13 would keep the led off in that case.

If this is the case it just further proves the law of "unintended consequences". While the thought of using a op-amp to 'unload' the pin 13 led current burden from pin 13 was a good idea in principal, it appears that it can leave one with random pin 13 behaviour when pin 13 is not being used by the user's sketch.

Comments?

Lefty

Well that's weird. I can confirm what Lefty just said. With this sketch loaded:

void setup ()
  {
  pinMode (13, INPUT);
  digitalWrite(13, LOW); 
  }  // end of setup

void loop () { }

On my Rev3 board, pin 13 is lit!

And connecting pin 13 to ground via a 1M resistor turns it off. So sounds like his theory is correct.

I suppose they did that to "not load" the SCK line with the LED, however the side-effect appears to be what you describe.