next topic »

[on:]

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.

[Reply #1 on:]

So, you have wiped out the bootloader when using the ISP programmer..

[Reply #2 on:]

did you set the fuses?

[Reply #3 on:]

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...

[Reply #4 on:]

Is the crystal the right 16Mhz value and the crystal caps are in the right value?

[Reply #5 on:]

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.

[Reply #6 on:]

fuses are set accordingly, E/H/L = 0xFF/0xDE/0x05.

Did you mean to write "L/H/E"?  Or is that really how you set the fuses?

[Reply #7 on:]

Did you mean to write "L/H/E"?

Ha!  Yes, I meant L/H/E.  Maybe I have dyslexia   Thanx for the catch!

[Reply #8 on:]

How much time do you want to spend troubleshooting?

[Reply #9 on:]

Hmmm, I've been asking myself that question as well.  Can you give me the Reader's Digest version of what sort of thing you have in mind?

[Reply #10 on:]

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.

[Reply #11 on:]

Yes, 16MHz crystal with 18pF caps as specified in the crystal datasheet.

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.

[Reply #12 on:]

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.

Yep, was thinking about something like that.  Thanks for your input!

[Reply #13 on:]

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?

[Reply #14 on:]

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.

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.