I have a new ATmega328P which seems to program just fine via ICSP. However, if I program it with the Arduino bootloader, while that seems to go fine, I then cannot upload a sketch from the Arduino IDE. Reset causes an LED on PB5 to blink as usual, but upload fails with the typical:
avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51
If I put another new chip (although from a different source) through the same process, then all is well.
My conclusion is, something may be amiss with the USART. So maybe to ask this question is to answer it, and perhaps I'm just wondering whether others have experienced similar situations. I've only done very limited testing, but the "bad" chip will at least blink LEDs on Ports B and D, notably PD0 and PD1.
Yes, I'm using the Optiboot bootloader, and fuses are set accordingly, E/H/L L/H/E = 0xFF/0xDE/0x05. And I get the same result whether I burn the bootloader from the Arduino IDE, or do it myself with avrdude. Have done this successfully multiple times, with several chips, using both methods, so I'm fairly comfortable with the process. It's just this one chip...
Yes, 16MHz crystal with 18pF caps as specified in the crystal datasheet. I have similar setups on (a) a target PC board, and (b) a breadboard. I can put the chips in either, same results. Also have two different FTDI interfaces, same results with either. I do believe I have the issue well isolated to the chip itself.
You suspect the USART is a problem so try a simple test... upload and test an echo-back Sketch using ICSP. Try a low baud rate (9600) and a high baud rate (115200). If that works, the USART is very likely working correctly.
[quote author=Jack Christensen link=topic=59394.msg427882#msg427882 date=1303696279]
Yes, 16MHz crystal with 18pF caps as specified in the crystal datasheet. [/quote]
The value specified in a crystal datasheet is typically its required load capacitance (Cl). To go from this to picking external capacitors, the formula is:
C = 2 * Cl – Cs
Cs in the above formula is the total stray capacitance at the XTAL1 and XTAL2 pins. A reasonable estimate for stray capacitance is 5 to 10 pF and a common specification for a 16MHz HC49/S crystal is a required load capacitance of 15pF. Feeding this into the above equation we can calculate C = 2 * 15 pF – Cs. This suggests that external capacitors should be somewhere in the 20pF to 25pF range.
For a recommended Cl of 18pF, range would be 26pF to 31pF. If you’re using a pair of 18pF capacitors with a recommended crystal Cl of 18pF, you’re out of range. In such cases it may work on some AVR’s, but marginally so.
BenF:
If you’re using a pair of 18pF capacitors with a recommended crystal Cl of 18pF, you’re out of range. In such cases it may work on some AVR’s, but marginally so.
BenF, yes that's what I have on the breadboard setup. OTOH, the target board came with the crystal and caps, don't have xtal specs, so have to assume they did it right. Appreciate your input, I'm not terribly familiar with crystal oscillators, so I learned something!
In what way might things be marginal? I did happen to check my clock frequency on the breadboard as a little experiment recently, and it was roughly within 0.002%. The crystal I'm using is Digi-Key part number 887-1244-ND, along with 18pF caps as I said.
The ATmega328P datasheet gives "initial guidelines" of 12-22pF for C1 and C2 when operating between 8 and 16MHz, so I thought I was in the ballpark. Of course they don't know what crystal people might select. Maybe they should have refrained from giving that advice?
Did this, and it works fine, input and output, 9600 and 115200 bps. So much for my USART theory. Once I burn the Optiboot loader again, I still get the same results, cannot upload sketches to the one chip from the Arduino IDE. Also swapped the xtal and discrete capacitors for a ceramic resonator with built-in caps, and that made no difference either. Going to try a different bootloader (ATmegaBOOT_168_atmega328.hex, i.e. Board=Arduino Duemilanove or Nano w/ ATmega328). After that I think I've run out of ideas. Have this feeling I'm missing something obvious, but I don't know what it could be.
Interesting, the Arduino Duemilanove or Nano w/ ATmega328 bootloader works like a champ! So maybe not a bad chip. I don't know anything about the bootloader internals, to be able to guess why the one works and not the other. Maybe the Optiboot loader should only be used with the Uno (because of the ATmega8U2 interface)? Maybe timing is different? I've used the Optiboot successfully in several non-Uno instances, but maybe I've just been lucky up until now.
Appreciate the suggestions and interaction, it kept me going. Very nearly chucked the chip, but now I'm glad I didn't, might have learned something in addition to saving the chip. I think I have one more raw chip, will have to try with that one. That'd be my luck, toss the one, and then the next one I try does the same thing!
Reprogrammed my chip with the Optiboot loader, and indeed I still cannot upload to it. Without doing anything else, I took it and put it onto a real Uno board, and uploads work fine. Took the chip from the Uno board (heretofore untouched) and put it on my breadboard and it works fine there too. Curiouser and Curiouser. Maybe the one chip is marginal in some way, and Optiboot brings out the worst in it, at least when trying to upload to it with an FTDI interface.