1

I am using Atmega328p with arduino bootloader in a project. There happens to be an LED connected on SCK pin. During Start (or restarts), the LED appears to flicker a couple of times (3 times to be exact). I don't want this to happen. I can change the connections but I would prefer a software solution because hardware change means a PCB modification.

I probed the SCK pin and I got some expected waveforms. There were two different cases:

1) When I powered the arduino using USB to serial programmer i.e. Tx Rx connected to a PC:

with UART connected

2) When I powered the arduino with an external power source (the case with my project):

Without UART

This is what I think:

1) As mentioned in this thread, the bootloader has a piece of code which makes it act that way. The bootloader code has a pin definition file which declares SCK pin as a LED and blinks it a couple of times to indicate that it has entered the bootloader. I found the code here:

#if defined(__AVR_ATmega168__) || defined(__AVR_ATmega328P__) || defined(__AVR_ATmega328__) || defined(__AVR_ATmega88) || defined(__AVR_ATmega8__) || defined(__AVR_ATmega88__)
/* Onboard LED is connected to pin PB5 in Arduino NG, Diecimila, and Duemilanove */ 
#define LED_DDR     DDRB
#define LED_PORT    PORTB
#define LED_PIN     PINB
#define LED         PINB5

Other relevant piece of code is here.

In this case, changing the LED definition to PINB4 and burning the bootloader and program again should take care of the issue. However this didn't work out for me. This is what I did exactly:

a) Opened the file D:\Program Files (x86)\Arduino\hardware\arduino\avr\bootloaders\optiboot\pin_defs.h

b) Modified the PINB5 to PINB4 on line 6.

c) Saved the file, burnt the bootloader and then program.

d) Powered up the chip and tested whether I am getting those 3 pulses. I got those 3 pulses.

(Even though it didn't work, I am still going to try it a few more times just in case I might have made an error.) :(

2) This brings me to second thought that since atmega328 accepts code through SPI by default, it checks for incoming data by clocking the SCK pins 3 times during startup. In this case, a software fix won't do anything.

What do you guys suggest? Should I go for the PCB modification or is there still some hope left?

Ignacio pointed out that I can disable bootloader to get rid of the issue. I want to program the chip using arduino IDE (preferably via UART) but I can consider SPI as well in case everything else fails.

Note: I am not sure whether this post is more suited for EE or Arduino. In case you guys(mods) think I'd get better suggestions there, feel free to move my post to Arduino.

10
  • Can you explain in more detail how modifying the bootloader "didn't work out"?
    – Dave Tweed
    May 5, 2016 at 12:15
  • I modified PINB5 to PINB4, burnt the bootloader, burnt the code and powered the circuit. I was still getting the same 3 pulses. May 5, 2016 at 12:19
  • It might make more sense to set LED_START_FLASHES to 0. There is code in the file you linked to that does that as long as it hasn't been defined elsewhere.
    – Dave Tweed
    May 5, 2016 at 12:26
  • I can try that Dave. I am more of a hardware guy rather than coder. I'll try what you suggested and update my question. Thanks May 5, 2016 at 12:27
  • In that case, you need help from the people who understand the details of the Arduino software. Migrating.
    – Dave Tweed
    May 5, 2016 at 12:31

2 Answers 2

1

I compiled Optiboot a while back using the shell script below. This is for Linux, you may need to adapt slightly for other operating systems.

BIN_LOCATION='/home/nick/Development/arduino-1.6.5-r5/hardware/tools/avr/bin'

$BIN_LOCATION/avr-gcc -mmcu=atmega328p \
    -D__AVR_ATmega328P__ \
    -DF_CPU=16000000L \
    -DBOOTLOADER_ADDRESS=7E00\
    -DBAUD_RATE=115200 \
    -DLED_START_FLASHES=0 \
    -DOPTIBOOT_FIX=1 \
    -Os \
    -gdwarf-2 \
    -fno-inline-small-functions \
    -fno-split-wide-types \
    -fno-tree-scev-cprop  \
    -fno-exceptions -ffunction-sections -fdata-sections \
    -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -fno-jump-tables  \
    -fno-keep-inline-functions -fno-common \
    -std=gnu99 \
    -Wl,--section-start=.text=7E00 \
    -Wl,--relax -nostartfiles \
    -Wl,--gc-sections \
    -ooptiboot.elf optiboot.c 

rm -f optiboot.hex

$BIN_LOCATION/avr-objcopy -O ihex --set-section-flags=.eeprom=alloc,load \
    --no-change-warnings \
    --change-section-lma \
    .eeprom=0 \
    -R .eeprom optiboot.elf optiboot.hex

$BIN_LOCATION/avr-objdump -j .sec1 -d -m avr5 optiboot.hex > optiboot.lst

You will need to find where your copy of avr-gcc and insert that into the first line above.

Notice I have changed the define for LED_START_FLASHES to be zero above. That should fix the issue.

To save you the trouble of doing that, I have made a "no blink" version for the Atmega328 and put it here:

http://gammon.com.au/Arduino/optiboot_no_blink_atmega328.hex

Warning - the script above compiled the "no blink" version OK, but using the latest version of the Optiboot.c code, and the latest compiler, makes a .hex file that is four bytes too long, for reasons I can't work out. However it compiles fine if you omit the blinks, because there is less code there.


Note re the LED on D13. Because the LED is driven by an op-amp (on the Uno), it will flash even with the above code. However that is because the op-amp has a high-impedance input. If you use a pull-down resistor on D13 it won't flash.


Now that I look at the download, it is so short I may as well include it here:

:107E0000112482E08093C00088E18093C10086E065
:107E10008093C20080E18093C40084B714BE81FFC8
:107E2000C8D088E1809360008DE080936000259A3F
:107E300018E108E033E0F32EEE24EA94DD24D39435
:107E400045E0C42E51E1B52EA7D0813429F481E05C
:107E5000BED083E09AD096C0823419F484E1B7D0C2
:107E600091C0853419F485E0B2D08CC0853599F481
:107E700093D0C82FD0E0D0930102C09300028CD0E1
:107E80009E01382BC901880F991F9093010280939E
:107E9000000297D077C0863529F484E098D080E03E
:107EA00074D070C0843609F042C07ED0E0910002E8
:107EB000F0910102F0925700E895C0E0D1E002C0D5
:107EC0006BD089938C2F90910202C917C8F38C1B39
:107ED00001C0E9929C2F980F9034D8F372D007B666
:107EE00000FCFDCF40910002509101029A01A0E0F8
:107EF000B1E08C911296FD013197608190E0962B54
:107F0000F9010C01D0925700E89511242E5F3F4FE4
:107F1000A038F1E0BF0769F7FA01C0925700E89571
:107F200007B600FCFDCFB0925700E8952BC0843710
:107F3000B1F43AD046D0E0910002F0910102CF01B5
:107F40000196909301028093000284911ED080914B
:107F500002028150809302028111EDCF13C0853758
:107F600041F42FD08EE111D085E90FD08FE00DD0F4
:107F700009C0813531F4109360000093600021D076
:107F800001C01FD080E101D05FCF9091C00095FF6C
:107F9000FCCF8093C6000895A8958091C00087FF0C
:107FA000FCCF8091C6000895F7DFF6DF80930202D0
:107FB000F3CFE0E6F0E088E180831082EE27FF2730
:107FC0000994EADF803209F0F4DF84E1DECFCF9359
:0C7FD000C82FE2DFC150E9F7CF91F3CFDA
:0400000300007E007B
:00000001FF

Just save that as optiboot.hex.

5
  • Thanks a lot, Nick. I'll be using the hex file that you generated for me. I really appreciate your help and efforts. I'll give it a go and update you about the results. Have a nice day, Sir. May 6, 2016 at 3:28
  • I downloaded the file and burnt the bootloader. The issue went away. Thanks a lot Nick. You helped more than I asked for. May 7, 2016 at 10:02
  • Hey Nick, the bootloader seems to be causing some RESET issues. Can you check once. Sometimes I feel that I am having difficulty uploading code or resetting the chip by grounding the RESET pin. Can you check if you disabled the reset pin in the bootloader? Thanks May 16, 2016 at 17:16
  • It isn't possible to disable the reset pin, whatever bootloader you use. You might do it with a fuse setting, but the bootloader itself can't do it.
    – Nick Gammon
    May 17, 2016 at 5:58
  • I posted a new question here. Can you please take a look? Thanks May 17, 2016 at 6:04
1

There is nothing in the default megaAVR initialization that causes SCK to behave in this manner; it is all caused by the bootloader.

Fortunately all you have to do to solve this is disable the bootloader. Unprogramming the BOOTRST fuse (ext:0) will cause execution to start at address 0 instead of the beginning of the bootloader on reset.

5
  • 1
    But then I won't be able to program the chip using Arduino IDE. I need that functionality. Any other suggestion? May 5, 2016 at 12:14
  • Sure you will. You'll simply program it via ISP instead of serial. May 5, 2016 at 12:14
  • Ohh that's what you meant. I can consider this option. However is there a way I can keep UART programming feature intact? May 5, 2016 at 12:20
  • If I was going to then I'd just remove the whole LED blinking part. Which I wouldn't, because I'm far too used to ISP to put up with serial programming. May 5, 2016 at 12:22
  • Dave suggested something in comments - seems equivalent to deleting the LED blinking part. I was just hoping that there is a code way to do which is there it seems after reading your answer and his comment. I'll give it a try and let you guys know. Thanks a lot for posting the answer. (+1) May 5, 2016 at 12:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.