Can an MCU be partly bad?

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.

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

did you set the fuses?

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

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

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.

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?

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

How much time do you want to spend troubleshooting?

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?

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.

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

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! :slight_smile:

I suspect it's too late now but when you tried using the processor with the Uno / Optiboot bootloader did you remember to select Arduino Uno?

So maybe not a bad chip.

Certainly does not seem to be.

Maybe the Optiboot loader should only be used with the Uno (because of the ATmega8U2 interface)?

Nope. The bootlaoder has no awareness of what's on the other side of the serial port. It's all just bytes coming and going through the serial port.

Maybe timing is different?

The baud rate is different.

I've used the Optiboot successfully in several non-Uno instances, but maybe I've just been lucky up until now.

I'd say unlucky this time. Unless you have stumbled on a bug, Optiboot should work fine.

It's good to know the life of an AVR processor has been spared!

I do believe I did. Actually probably not too late, I'd bet I could recreate the situation.

It's good to know the life of an AVR processor has been spared!

Indeed! 8)

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.

Auto-reset not working as it should?