Go Down

Topic: Mega 2560 - Led 13 often on without code (Read 1 time) previous topic - next topic

retrolefty

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

tres

#16
Jan 29, 2013, 07:32 am Last Edit: Jan 29, 2013, 07:34 am by tres Reason: 1
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

Nick Gammon

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.

retrolefty

#18
Jan 29, 2013, 02:02 pm Last Edit: Jan 29, 2013, 02:22 pm by retrolefty Reason: 1

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.


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.


Code: [Select]

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

Nick Gammon

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

Code: [Select]

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.

Go Up