I have 2 arduino Duemilanoves (328 version) and I finished my latest project. However with this project, I wanted to put the arduino chip on its own board so I don't have to use the whole duemilanove shield. I looked at the chip and it was the ATMEGA328P-PU chip, so I ordered one on Sparkfun (AVR 28 Pin 20MHz 32K 6A/D - ATMega328P - COM-09061 - SparkFun Electronics) without the bootloader because writing one looked pretty straight forward since I had 2 arduinos as is. However I'm having a LOT of difficulty programming this chip. (I thought It'd be easy especially since both of my Arduino boards had the ATMEGA328P-PU chip in them)
I set up one arduino as an ISP, and took the chip out of the other and installed the blank chip (on the right Arduino) like this:
Anyways, I selected my com port, uploaded the ISP sketch, and then every time I try to run the burn bootloader command, I get:
avrdude: stk500_getsync(): not in sync: resp=0x15
I can't figure out what the issue is for the life of me.
If anyone else can help me solve this, I'll be ever grateful. (for now on, I'm paying extra to get the chip with the boot loader.... This is discouraging.)
I've used Duemilanove many times to burn bootloaders, but not connected to
a 2nd Duemilanova. What I would recommend is
forget the ICSP header, and connect directly between pins D11..D13 of the 2 boards,
and then connect D10 on left to Reset on the Power header of the target.
The reason for this is, it's too easy to get the pins swapped on the ICSP header - despite
what your picture shows.
Do not connect 5V between the boards. Instead connect the Vin pins on the Power headers.
This is because you're driving the 5V regulator of the target board backwards.
which will install OptiBoot on the slave Arduino's chip. OptiBoot is the newest bootloader, used by the Uno etc.
Because it installs the bootloader directly it bypasses avrdude, which will get rid of any weirdness between the PC app and the master Arduino sketch.
Yes, there is no good reason any 328P based board shouldn't have the optiboot loader installed on it. Using OptiBoot sketch or Nick Gammon's ATmega_board_programmer sketch make the task easier then using the arduinoISP method.
That's likely not to be OP's problem, as the target board is just a carrier. Once
the ArduinoISP sketch is loaded into the programming chip, you get Duemilanove
or optiboot [UNO] bootloader burned, simply dependent on which board you choose
in "Tools > Board". No? So, that doesn't matter. His problem is something else.
oric_dan:
That's likely not to be OP's problem, as the target board is just a carrier. Once
the ArduinoISP sketch is loaded into the programming chip, you get Duemilanove
or optiboot [UNO] bootloader burned, simply dependent on which board you choose
in "Tools > Board". No? So, that doesn't matter. His problem is something else.
Yes, and his problem symptom sounds like the common one gets if they don't defeat auto-reset on the programmer arduino running the arduinoISP sketch before it can syn up with AVRDUDE and start the process of burning whatever bootloader is selected (via board selection) to the 'target' arduino board.
The two other standalone boot burner sketches mentioned solve that kind of problem as the IDE and AVRDUDE is not involved at all once the sketch is loaded into the arduino doing the programming, as the bootloader code is included in the programmer sketch code.
Thanks guys for suggesting the OptiLoader! I didn't think it'd work since I had a Duemilanove board instead of a UNO board. However after I loaded OptiLoader, the bootloader burned! It works just fine, however I need to select UNO from my board when I upload the sketch. (That's not a big deal though.) Could I reload the bootloaders for my two Duemilanove bootloader chips to the OptiBoot bootloader? What's the real difference between the UNO and Duemilanove anyways? I know the UNO has more memory, and is slightly faster, but is there any other major difference?
Well, no, it doesn't explain why he was unable to program the duemilanove bootloader into his blank chip.
However, it provides an alternative easier method for burning bootloaders onto blank chips (but only optiboot), so if optiboot is acceptable, it can make the problem irrelevant.
What's the real difference between the UNO and Duemilanove anyways? I know the UNO has more memory, and is slightly faster, but is there any other major difference?
That is about it, but slightly faster means twice the baudrate when uploading new sketches. Also the Uno fixes a bug in the Duem bootloader which made it incompatible with using the watch dog timer. The main difference after loading optiboot onto a Duem board is that the arduino IDE will think the board is a Uno board from then on and that is the board you have to select before uploading sketches.
The main difference between the BOARDS is that the Uno uses a second AVR chip for the Serial/USB converter, while the Duemilanove has an FTDI chip. This means that the Uno can have the Serial/USB converter firmware reloaded as well as the main CPU sketch, permitting it to mimic other USB devices (mouse, keyboard, midi, game controller, etc) rather than just a serial port.
The main difference between the old bootloader and Optiboot is that Optiboot runs the serial port at 115200bps instead of 57600bps, supports a smaller subset of commands (no EEPROM, for instance), and takes up less space.
No EEPROM? where is it used in the boot process and why mention it?
this isn't a trick or "Other" question, I really don't know the difference and I haven't yet run into this. A link is more than good enough or just point...
No EEPROM? where is it used in the boot process and why mention it?
It's theoretically a good idea for your upload step to be able to load values into the chip's EEPROM as well as to flash. EEPROM is non-volatile storage for data, accessible via a library and readable and writable on a per-byte basis during execution of your sketch. FLASH is writable only a page at a time, and only by the bootloader. I don't think that the Arduino ide has ever supported loading initial values into EEPROM, though; it would take splitting off a separate .hex file from the .elf file, and a separate avrdude command or option.
Not only does optiboot not support this, but it fails to notice the difference between EEPROM and FLASH, so that if you DO try to write EEPROM, it will overwrite some location in flash instead...