UNO R3: Programmer is not responding (not a noob)

Using Arduino IDE 1.x
1

Hello fellow hackers.

Questions:
0 - did I blow up the oscillator?
1 - did I blow up a fuse (anyway a fuse could not be causing these issues right)?
2 - a blown capacitor could be causing clock speed issues?
3 - throw it out? I am willing to replace any SMD component by hand!
4 - what can make the programmer not respond anymore?

If you're a arduino or avr-ninja, I challenge you to this one:

0 - I have an official made-in-Italia Arduino Uno R3 with removable ATMEGA. Socket 28 DIP. Also got myself a bunch of ATMEGAs. I also have a chinese knock-off uno with the SMD ATMEGA which obviously cannot be replaced.

1 - while programming a batch of 5 ATMEGA328P-PU for installing on custom perfboard projects, I made a mistake at one point and placed a chip reversed on the socket. I didn't freak out at first. But when I realised that I could no longer program the chips, I got pissed.

2 - The program that I was trying to flash on the chips has something to do with the SLEEP functions, WTD watchdog timer, etc... kind of low-level because it operates at register level. If I remember correctly, basically puts the board into hibernation for 8 or 9 seconds and when it wakes up it goes over the loop() function only once checking for an analog signal, and sleeps again. I might have uploaded some code that fiddled with the clock speeds too. But I'm not sure about what could be on this board's program right now... (I don't know if the programs stay only on the ATMEGA chips or anywhere else on the UNO board [although I would assume chip-only])

3 - I use windows7x64 and linux and am quite experienced with these environments. I believe I can debug a lot on my own, but here I'm really stumped. Let's go through a list of facts and you tell me if there's something I forgot to check:
3.1 - when I plug the unor3 board without any ATMEGA chip on it, the computers recognize it as an arduino uno USB device and the proper serial-COM port is created. I guess that the FTDI is intact.
3.2 - ArduinoIDE is able to detect the board too, both on windows and linux
3.3 - when plugged in, the ON led and the "L" led stay on, never switch off.
3.4 - when I do the above WITH an ATMEGA on the board, same results happen.
3.5 - I used the chinese knock-off to program some chips by using the chinese as an ISP, and this worked out fine. I was able to test my perfboards and it worked. But now as I'm writing from windows, this doesn't work anymore!!! What the heck...... >:-(
3.6 - I have the good habit of writing my setup() function so that it blinks LED 13 about 10 times really quickly before it finishes. This is a way I can be sure visually that my chip is starting up properly if I reset it or power is lost. Interestingly the ATMEGAs that I managed to program with the chinese-as-isp DO blink when I put them on the unor3 board and power-on. However they blink EXTREMELY EXTREMELY slowly, like the clock of the unor3 board is 1/10 of what it should be.
3.7 - I've tried and failed to reupload a bootloader, but I don't think this is the issue since it sits on the ATMEGA right? My problem seems to be with the board really.

Cheers!

2

Not a ninja :wink:

Have you tried the loop-back test as described in a sticky in this section? You might very well have fried part of the 16U2 on the board.

3

jandrioli:
3.6 - I have the good habit of writing my setup() function so that it blinks LED 13 about 10 times really quickly before it finishes. This is a way I can be sure visually that my chip is starting up properly if I reset it or power is lost. Interestingly the ATMEGAs that I managed to program with the chinese-as-isp DO blink when I put them on the unor3 board and power-on. However they blink EXTREMELY EXTREMELY slowly, like the clock of the unor3 board is 1/10 of what it should be.

When you program a new or unknown sourced ATmega328P you must set the fuses to the values you want. The default could be anything, but often they run at 1MHz, so that would make a sketch which was written for a 16MHz processor run slowly.

If you have the ISP programmer connected well enough to upload a sketch to it, it should be equally able to burn the bootloader. Burn the bootloader first, because that is when the fuses are set. Then upload the sketch using ISP, or upload using regular serial. If you upload the sketch using ISP, it will erase the bootloader. If you upload the sketch using regular serial, the bootloader will remain on the chip.

jandrioli:
3.7 - I've tried and failed to reupload a bootloader, but I don't think this is the issue since it sits on the ATMEGA right? My problem seems to be with the board really.

It's the issue; you need to burn the bootloader and therefore set your fuses.

4

I'm with dmjlambert. You say "3.7 - I've tried and failed to reupload a bootloader, ...."
Why did this fail?
What error message(s) did avrdude produce?
(It's very unlikely that the oscillator is dead, and the next thing to look at that can influence speed is the fuse settings.)

5

Funny. I configured this thread to send me alerts, but received none. And junk box is clean...
So sorry for not responding earlier, and thanks to all 3 who answered.

@sterretje - I'm happy to report that my UnoR3 board seems to be alive and kicking. I borrowed a diecimilia to test my ATMEGAs and successfully burnt a bootloader to one of my ATMEGAs.
So not only I found that my board still works but also revived an ATMEGA.

@dmjlambert and @OldSteve - I've currently got 3 ATMEGAs that simply do not respond at all when I place them on the UnoR3 board: my confuser (linux AND windows) tells me "bad signature blablabla Yikes!" so I initially assumed they were dead.
However if I place them on a perfboard that I built, they work! That means, I can see the LED13 blinking really extremely terribly slowly. That's probably because of some sketch I had programmed way way back I presume, but now instead of running at 16MHz it's running at sth like 1MHz.

I will study this FUSE topic a little more into detail, for the moment I know nothing about it... At first I though this was a series of physical fuses but now I found this is actually something in the chips memory/registers. What a strange nomenclature.............