I've been using Nick Gammon's Atmega_Board_Programmer.ino to flash the "Lilypad (8 MHz) loader" to run the chip in standalone mode.
Then I use AVRdude to upload a simple "sequential LED scrolling" hex file compiled in Atmel Studio 6.1
However, this seems to leave the Arduino bootloader on the chip, is that correct? Because when I power on the IC, it blinks the LED at port 13 (pin 19) just once, (arduino bootloader) then there's a short delay (maybe 3/4 of a second), then my program starts.
I wanted to get rid of the arduino bootloader altogether to avoid the "blink port 13 & delay". I was able to do it, but now I can't... Anyone has any idea?
When you say you're uploading your sketch using AVRdude, what hardware connections are you using to program it? If you're using serial (via FTDI breakout or cable) then the bootloader will be invoked and it will protect itself during the upload. If you're using an ISP programmer of some sort then you're replacing the bootloader.
I'm using ArduinoISP connected to the SPI pins on the target chip, as described in http://arduino.cc/en/Tutorial/ArduinoISP (bottom left, without extra components)
So strange that it was succesfully getting rid of the bootloader two days ago, and last night it never wanted to leave it again.
Here are my fuse settings as per Nick Gammon's fuse calculator:
You are including the -D option which will not erase flash before uploading. This option will prevent the bootloader from being erased. Just remove the -D option from this command line and avrdude will erase all the flash, which gets rid of the bootloader before uploading the sketch.
To "get rid" of the bootloader, you will need to change the fuse setting of the BOOTRST fuse in the High Fuse byte, so that it is "unprogrammed" (1)
For a M328, you'd want 0xDF instead of 0xDE
This fuse controls whether the chip starts execution at the beginning of the application section (0x0000) or the beginning of the Bootloader section (variable depending on bootloader size), so even if you've erased the actual bootloader, you still need to set it correctly... (Conversely, even if you have bootloader code present, it won't be executed if BOOTRST isn't enabled.)
If you just want to get rid of the delay, you program the fuse to jump straight to your program code (address 0) rather than the bootloader code, as westfw said.
Hi Nick,
I've meet tonight such a interesting problem:
I've tried to use my AVR Dragon to program a atmega328p with arduino bootloader. But it just can't get the correct ID of the chip. then I've tried the m328p on a arduino board. I works just fine (Blink a led on pin13). Then I tried my adafruit usbtiny. Avrdude told me "Initialization failed, rc = -1".
I just wanna tried some AVR with my old Arduino. But it seems the bootload stopped the programming process?
Without more details about how you used your Dragon it is hard to say. However be aware that the AVR products (Dragon, AVRISP) do not supply power to the target board. You need to supply that yourself.
FIrstly I made the circuit following this video: AVR Programming - AVR Dragon Introduction - YouTube
And I've been confirmed with a original m328p (without Bootload fresh unboxed) the circuit works as it should be. (In atmel studio 6 I can read the target Voltage and ID) and I do check the voltage of the circuit with a Multimedia. It's correct.
vinmred:
Any idea how to do this for an arduino leonardo?
I think you can just set the fuse to not use bootloader and upload a sketch via ISP (without the -D command line option)... If there are complications, they're related to USB, but I don't think there are.
westfw:
To "get rid" of the bootloader, you will need to change the fuse setting of the BOOTRST fuse in the High Fuse byte, so that it is "unprogrammed" (1)
For a M328, you'd want 0xDF instead of 0xDE
This fuse controls whether the chip starts execution at the beginning of the application section (0x0000) or the beginning of the Bootloader section (variable depending on bootloader size), so even if you've erased the actual bootloader, you still need to set it correctly... (Conversely, even if you have bootloader code present, it won't be executed if BOOTRST isn't enabled.)
Well, if the board def you're using was meant to be used with a bootloader, and the flash was erased before you programmed it, you can get away with BOOTRST being left as it was when you bootloaded it - because the board def is leaving space for the bootloader that isn't there, so you don't run the risk of code being there (it will tell you the sketch is too big), and the blank flash will have 0xFF in it, and 0xFFFF is a no-op, so execution on reset will skid along the no-op's until it reaches the end of the flash, wraps around to address 0, the reset vector, and jump to the sketch.