Can an MCU be partly bad?

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?

Senso:
Auto-reset not working as it should?

Looks like it is, from the LED on PB5, and I've also tried hitting the reset switch.

Just to clarify ...

You have two (or more) ATmega328 processors.

At some point, you have installed Optiboot to two (or more) of these processors.

You have one processor that does not work with the bootloader but does work using ICSP.

The other processor(s) work correctly using the bootloader.

The processor that does not work does not work when installed in an Uno board and does not work using an FTDI board.

Is that correct?

Yes, except for the last which should read:

The processor that does not work does work when installed in an Uno board and does not work using an FTDI board. (But does work with FTDI and the ATmegaBOOT_168_atmega328.hex bootloader!)

No shotgunning here (sorry) :~

Which FTDI adapter are you using?

Have tried both the Adafruit FTDI Friend and the Sparkfun FTDI Basic. Same results with either.

One last test and then I'm out of ideas. Locate "boards.txt" (it's in the {ArduinoRoot}\hardware\arduino directory). Open "boards.txt" in your favourite text editor. Locate the "Arduino Uno" section; it should be first. Change "uno.upload.speed" to 117647. The line should look like this...

  uno.upload.speed=117647

Save and close the file. Test. Don't forget to change the baud rate back to 115200.

When uploading, after the compile, I immediately get:
avrdude: serial_baud_lookup(): unknown baud rate: 117647

What is the significance of the number 117647?

Rats. I can't imagine why avrdude would filter the baud rate but it does so we're done.

117647 is the actual baud rate at the processor. The formula is F_CPU / (8*(UBRR0+1)) = 16000000 / (8*(16+1)).

Oh, wait. That was a dumb test. You already did an echo test.

LOL, no worries, it was quick and painless enough. Thanks for your help, I certainly do appreciate your attention to this puzzler!