Go Down

Topic: Strange behaviour of pin13 on breadboard Atmega 328 (Read 847 times) previous topic - next topic

bperrybap

While this is unrelated to the bootloader leaving the pin in output mode,
this LED output pin issue when LED flashes is set to zero was actually fixed in the official version of optiboot 5 years ago:
https://github.com/Optiboot/optiboot/commit/0ee526aa81858a95803b394fed5f46ce5a1444d2#diff-aa6fbd4fbd422af50b97d38d37fe1e1e

So this is a case of the Arduino IDE using/providing an older version of the optiboot bootloader.
(5 years old is quite old....)
It would interesting to know which version of the bootloader are they actually burning into the official boards to see if it matches the source they are providing.

One of the first things I always do with any AVR Arduino board I buy is to burn a bootloader that I have built from source.
That way I know what bootloader code it is in it, particularly for the clone boards.
That and I rarely ever use the LED pin for anything, since the pin is driven as an output by the bootloader.

In the larger picture, using the LED pin can be difficult given the various different LED circuitries used on that pin over the years.
Some will create loads and some will cause the LED to light up when the pin is input mode.
This is one of the reasons I try to avoid using the pin.

--- bill

bperrybap

#16
Jun 17, 2018, 09:05 pm Last Edit: Jun 17, 2018, 09:07 pm by bperrybap
Oh come on YOU.

I have more enjoyable things to do with my time than study bootloader code looking for some arcane feature I am not even aware it might have. Sheesh.

...R
Not aware? But I assume you know that the LED is blinked by the bootloader, right?

The bootloader blinks the LED.
That means the bootloader must control the LED pin which requires changing registers from their default state.
Using a pin that is used as an output by the bootloader comes with limitations.
You must understand those limitations to be able to use it.

I'll agree that the bootloader probably should put the pin back to its default state before calling application code, but even if it did, there are still limitations on how that pin can be used because the bootloader is using it to control an LED, and there is also external h/w dangling off that LED pin. The external h/w connected to the LED pin on the Arduino boards that can vary between Arduino board versions, and depending on that external h/w there are different limitations and/or restrictions.

So it isn't just a s/w issue in the bootloader of using that pin and leaving it in output mode, there are also h/w considerations that vary by board and board version that must be taken into consideration when using that pin.
i.e. if you rebuilt the bootloader to never touch that pin, you still have certain limitations when using that pin that can vary depending on which Arduino board and which version of the board you are using since there is extern h/w attached to that pin.

--- bill

bperrybap

Ok, so some of this LED pin stuff is coming back to me.
I remember not being happy with how it worked, particularly on the newer Arduino boards.
With the newer onboard LED circuit used on the newer revision boards, the LED is on whenever the pin is not driven low.
This is very different from the older design that required driving the pin high to turn on the LED.

So if you went in an "fixed" the bootloader to put the LED pin back into input mode, the LED would be left on,
That is likely a behavior that many people may not understand and may not like.

IMO *that* is a h/w design issue on the Arduino boards as I don't think a pin in input mode should turn on an LED.

Like I said, using the LED pin has limitations.

--- bill

Robin2

But I assume you know that the LED is blinked by the bootloader, right?
It never occurred to me. I am using a bootloader with an Atmega 328 on a breadboard and I have no LED connected to it to observe the bootloading process.

I have been using Nick Gammon's bootloader program. I have no idea what bootloader code it uses - it just works.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

bperrybap

Seems like it might be easier to use a USBasp device along with PeterVH & my version of the USBasp firmware.
Cheap, fairly foolproof with builtin support in the IDE and auto sets the SCK clock to the fastest reliable rate the part can handle including for virgin parts or parts not using a crystal.

That way you know what bootloader you are getting or could use it to upload the code instead of using a bootloader at all.
With no bootloader, your issue with the LED pin completely goes away.

--- bill

Southpark

#20
Jun 17, 2018, 11:58 pm Last Edit: Jun 18, 2018, 12:01 am by Southpark
The safest way is to purposefully initialise everything we're going to use.... like variables and pins, arrays etc. Otherwise, we need to make sure we truly know the initial state of the 'particular' board we're using. This probably goes for any kind of system, not just Arduino. True..... pin 13 is the odd-one-out pin, as it's the one that might be connected to the on-board LED (if there is one).

bperrybap

True..... pin 13 is the odd-one-out pin, as it's the one that might be connected to the on-board LED (if there is one).
It isn't just pin 13. pins 0 and 1 also can have issues as they are often connected to external h/w for the USB to serial interface.
And then there can be issues with pin collisions with built in h/w like I2C and SPI.

--- bill


Southpark

#22
Jun 18, 2018, 12:45 am Last Edit: Jun 18, 2018, 09:45 am by Southpark
It isn't just pin 13. pins 0 and 1 also can have issues as they are often connected to external h/w for the USB to serial interface.
And then there can be issues with pin collisions with built in h/w like I2C and SPI.

--- bill
Oh geez yeah. I agree. Pin 0 and 1 can be a real pain in the neck (for newbies and those not reading enough tutorials relating to Arduino input/output)!!!! For every arduino tutorial, that (along with other important things) should be one of the first things to write ..... at the very front of the tutorial.

However though, the little symbols that says TX0 and RX0 (next to pins 0 and 1) should draw some kind of attention....... eg. would prompt the inquisitive to ask what it means before using those pins.

But.... on the other hand, you'd think that newcomers are likely to use those pins ....... as many would say....'why not start with using pins 0 and 1?' -- since they're the first couple of pins to use from the low-number end. But then again, I think the arduino tutorials do tell us about which pins to use, and to not use pin 0 and 1 as regular input/output pins.

GoForSmoke

I avoid using pin 13 for input because of the led circuit but that only matters if there's a led circuit.
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

Robin2

Seems like it might be easier to use a USBasp device along with PeterVH & my version of the USBasp firmware.
If that comment is aimed at me I can assure you that any change from the nice simple system I have would not be "easier" than no change.

Now that I know the cause of the problem I can deal with it fully by including pinMode() commands in my code.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

bperrybap

#25
Jun 18, 2018, 09:45 am Last Edit: Jun 18, 2018, 09:46 am by bperrybap
I avoid using pin 13 for input because of the led circuit but that only matters if there's a led circuit.
It can still matter even if there is no led circuit.
If the typical Arduino bootloader is being used it will blink the LED at powerup and reset which might cause issues depending on the h/w attached to it.

For example, suppose something is hooked up to the LED pin and holds the LED pin low just after power up or low during reset, this would create a short when the bootloader attempts to drive the pin high to blink the LED.

--- bill

Robin2

For example, suppose something is hooked up to the LED pin and holds the LED pin low just after power up or low during reset, this would create a short when the bootloader attempts to drive the pin high to blink the LED.
Indeed.

We must be careful what we attach to pin 13.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

GoForSmoke

It can still matter even if there is no led circuit.
If the typical Arduino bootloader is being used it will blink the LED at powerup and reset which might cause issues depending on the h/w attached to it.

For example, suppose something is hooked up to the LED pin and holds the LED pin low just after power up or low during reset, this would create a short when the bootloader attempts to drive the pin high to blink the LED.

--- bill
I mode my pins though I have trusted the default LOW.

And now I have to watch out for pin 13 defaulting to OUTPUT HIGH?
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

Robin2

And now I have to watch out for pin 13 defaulting to OUTPUT HIGH?
It would have to be OUTPUT LOW to give the symptom that I experienced and which caused me to start this Thread.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

bperrybap

I mode my pins though I have trusted the default LOW.

And now I have to watch out for pin 13 defaulting to OUTPUT HIGH?
The short issue isn't about pin 13 defaulting to given level.
By default when the AVR powers up or is reset all pins are inputs so there never is a problem with any pin at that point in time.

But then time advances and if  you are using a bootloader, the bootloader runs which can change things and it does.

The bootloader that is used on AVR based Arduino boards reprograms some of the pins. (LED pin, and serial pins)
And while the bootloader can be built several different ways, it is typically built to blink an LED at  powerup and reset.
(behavior is slightly different depending on which bootloader you are using and which version you have but 3 blinks is the norm)

The Arduino boards hook an LED to a pin and the bootloader blinks that LED.

That means that the bootloader changes the pin hooked to the LED from being an input to an output to drive the LED.
It sets it low to turn the LED off, and then sets it high to turn on the LED and back to low to turn off the LED.

So if you have something connected to the pin used to drive the LED (typically pin 13) and that something is driving that pin (low or high; doesn't matter) you will have short when the bootloader runs since the bootloader reprograms the AVR port register from its default powerup/reset state  to drive the pin pin and the external h/w is also driving the pin.

Doesn't matter if the external h/w is driving the LED pin high or low, there will be short.

What is disappointing is that the Arduino boys changed the LED circuit on the newer boards and they could have resolved this potential short issue but they didn't.
i.e. they could have made it such the the LED would be off if the pin were an input or low and on if the pin were high or had the pullup turned on.
That way the bootloader could switch the pin from input to input pullup to blink the LED.
While that could still cause issues for external h/w it would never create a short as it would never be making the pin an output.

The current LED circuit, IMO, is worse from a visual point of view than the old circuit.
While it removed the LED load from the pin (which was good), the LED is now on unless the pin is driven low.
So if you have a newer board and make pin 13 an input, the LED is on.
This is different than the old circuit behavior which the LED was off unless the pin was a high output.

The only way to avoid this issue is to rebuild the bootloader to no longer blink an LED, or not to use a bootloader.
IMO, if I was using pin 13 and concerned about it, I'd ditch the bootloader.
ISP programmers are dirt cheap today and supported "out of the box" by the IDE so it isn't like it was 10 years ago where there was not a easy and inexpensive way to program the AVR including using the IDE to program the boards without using a bootloader.

--- bill

Go Up